AD-  78  4  1  35 


A  RESEARCH  PROGRAM  IN  THE  FIELD 
OF  COMPUTER  TECHNOLOGY 

Keith  W.  Uncapher 

University  of  Southern  California 


r 


Prepared  for: 

Advanced  Research  Projects  Agency 
May  1974 


DISTRIBUTED  BY: 


National  Technical  Information  Service 
U.  S.  DEPARTMENT  OF  COMMERCE 

5285  Port  Royal  Road,  Springfield  Va.  22151 


THIS  DOCUMENT  IS  BEST 
QUALITY  AVAILABLE.  THE  COPY 
FURNISHED  TO  DTIC  CONTAINED 
A  SIGNIFICANT  NUMBER  OF 
PAGES  WHICH  DO  NOT 
REPRODUCE  LEGIBLY. 


SECuPlTv  CLASSIFICATION  or  This  PAGE  When  Date  Inlet  sd; 


REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1  REPORT  number  |2  GOVT  ACCESSION  no.| 

ISI/SR-74-2  1 

3  RECIPIENT'S  catalog  number 

//./)  7#^ /■3S~' 

4  T|T  UE  lend  Subtitle) 

5  TYPF  OF  REPORT  A  PERIOD  COVERED 

A  Research  Program  in  the  field  of  Computer 
Technology 

Annual  Technical  Report 

May  1973  -  Mav  1974 

6.  PERFORMING  ORG.  REPORT  NUMBER 

7  author'*; 

•  CONTRACT  OR  GRANT  NUMBERS 

Keith  W.  Uncapher  (Principal  Investigator) 

DAHC  15  72  C  0308 

$  PERFORMING  ORGANIZATION  name  and  address 

USC  Information  Sciences  Institute 

4676  Admiralty  Way 
_ Marina  Del  Rey,  California  902S1 

10  PROGRAM  ELEMENT.  PROJECT.  TASK 
AREA  b  WORK  UNIT  NUMBERS 

ARPA  Order  #2223 

1  '  CONTROLLING  OFFICE  NAME  AND  AOORESS 

Advanced  Research  Projects  Agency 

12  REPORT  OATE 

May  1974 

1400  Wilson  Blvd. 

Arlington,  Virginia  22209 

13.  NUMBER  OF  PAGES 

\${ 

14  MONITORING  AGENCY  NAME  A  AODRESSO*  dlllerent  from  Controlling  Otllce) 

IS.  SECURITY  CLASS,  (ot  thle  report) 

IS*.  OECLASSIF' CATION ''DOWN  GRADING 
SCHEDULE 

16  Distribution  statement  (of  thla  Report) 

Distribution  unlimited.  Available  from  National 
Service,  Springfield,  Virginia  22151. 

Technical  Information 

17  OlSTPriByT|ON  STATEMENT  (ol  the  abetted  on  toted  In  Block  20,  II  dlllerent  from  Report) 


it  supplementary  notes 


19.  KEY  WOPOS  (Continuo  on  raverae  olio  II  naceaaery  and  I  don  t  tty  by  block  number) 

1:  automatic  programming,  domain- independent  interactive  system,  natural  lang¬ 
uage,  nonprocedural  language,  nonprofessior.al  computer  users,  problem  solving, 
problem  specification,  process  transformation,  world  knowledge 
2:  interactive  theorem  proving,  lemma  generator,  Pascal,  program  correctness, 
program  verification.  Reduce,  symbolic  executor,  verification  condition _ 

?0  A0S  ’  h  'Cl  ( Continue  on  rareraa  aide  II  neceaaary  and  Identify  by  block  number) 

This  report  summarizes  the  research  performed  by  USC/ In format ion  Sciences 
Institute  from  17  May  1973  to  16  May  1974.  The  research  is  aimed  at  applying 
computer  science  and  technology  to  problem  areas  of  high  DoD/military  impact. 

The  ISI  program  consists  of  ten  research  areas:  Automatic  Programming-  the 
study  of  acquiring  and  using  problem  knowledge  for  program  generation;  Program 
Verification-  logical  proof  of  program  validity;  Programming  Research  Instru¬ 
ment-  development  of  a  major  time-shared  microprogramming  facility;  Protection 


DD  , 1473  EDITION  OF  1  NOV  «S  IS  OBSOL ZTk 

S/N  0102-014-  6601 


I 


SECURITY  CLASSIFICATION  of  THIS  PAGE  r«9iwi  Deta  Entered) 


_  iiWiTy  CLASSIFICATION  of  This  PAGE'^hw  Dmtm  EnCrmd) 


19.  Key  Words  ''continued) 
generator 

3:  ARPANET,  control  memory,  microprogrammed  processor,  microprogramming, 
microprogramming  language,  microvisor,  MLP-900,  operating  systems,  resource 
sharing,  TENEX,  time  sharing,  writable  control  memory 

4:  access  control,  computer  security,  encapsulation,  error  analysis,  error- 
driven  evaluation,  error  patterns,  evaluation  methods,  protection  mechanisms, 
software  security,  verification 

5:  computer  security,  COTCO,  interactive  message  service,  message  service, 
reliability,  terminal  based  message  service 

6:  computer  terminals,  interactive  message  service,  office  automation,  CONNECT, 
nonprofessional  computer  users,  terminal-based  message  service 
7:  computer  network,  digital  voice  communication,  network  conferencing, 
packet-switched  networks,  secure  voice  transmission,  signal  processing,  speech 
processing,  vocoding 

8:  liquid  crystal  displays,  minimum  communications  terminal,  plasma  displays, 

portable  terminals,  video  display  system.  Xerox  Graphics  Printer 

9:  computer  networks,  configuration  control,  decisionmaking,  information 

display,  load  leveling,  network  data  base,  network  management,  network 

performance,  performance  analysis,  performance  measu  :ient 

10:  TENEX,  KA/KI,  PDP-10,  PDP-11/40,  resource  allocation,  computer  network, 

user  quotas,  ARPANET  interface 


20.  Abstract  (continued) 

Analysis-  methods  of  assessing  the  viability  of  security  mechanisms  of 
operating  systems;  Command  and  Control  Message  Technology-  study  of 
advanced  computer-based  techniques  for  military  message  handling;  Information 
Automation-  development  of  a  user-oriented  message  service  for  large  scale 
military  requirements;  Network  Secure  Speech-  work  on  low-bandwidth,  secure 
voice  transmission  using  an  asynchronous  packet-switched  network;  Techno1 
Support-  development  of  Xerox  Graphics  Printer  facilities,  portable  te;>»  -ils, 
and  military  office  terminal  system;  Network  Management  Information  Cetrer- 
development  of  a  network  performance-measurement  methodology;  and  Research 
Resot,  tees-  operation  of  TENEX  service  and  continuing  development  of  advanced 
support  equipment. 


i 


SECURITY  CLASSIFICATION  OF  THIS  FA D«f«  Knffd) 


ISI  SR-74-2 


A  Research  Program  in  the  field  of 


Computer  Technology 


ANNUAL  TECHNICAL  REPORT:  May  1973  -  May  1974 


prepared  for  the  Advanced  Research  Projects  Agency 


EFFECTIVE  DATE  OF  CONTRACT 
CONTRACT  i'XPI  RATION  DATE 
AMOUNT  OF  CONTRACT 
PRINCIPAL  INVESTIGATOR 


17  May  1972 

15  July  1975 

$6,616,798 

Keith  W.  Uncapher 
(213)  822-1511 


THIS  RESEARCH  IS  SUPPORTED  BY  THE  ADVANCED  RESEARCH  PROJECTS  AGENCY  UNDER  CONTRACT  NO  DAHC13  72  C  0300  ARPA  ORDER 
NO  2223.  PROGRAM  CODE  NO  3030  AND  3PIO 

VlFWs  AND  CONCLUSIONS  CONTAINED  IN  THIS  STUDY  ARE  TMT  AUTHOR  S  AND  SHOULD  NOT  BE  I NTE R PPE TF D  AS  REPRESENTING  THE 
OFFICIAL  OPINION  OR  POLICY  Qf  ARr*  THE  US  GO  v'F  RN  VI E  N  T  OH  A'jv  OTHER  PERSON  OR  AGENCY  CONNECTED  WITH  THEM 

THIS  DOCUMENT  APPROVED  POR  PUBLIC  RELEASE  AND  SALE  DISTRIBUTION  IS  UNLIMITED 

IS  FORM  A  ri()  V  SCI  l:K  CHS  IKSTIWTIi 

-if iTi  Aiinm\tlt\  'Xa\f  Marin.t  del  R?)/(.tt//fotwa  ()02‘)l 

<  :i  i)  w/ 


rXIl’IMSlTY  OF  UJl  IHf.RS  (  AIM OKXl.  I 


RESEARCH/ADMINISTRAT ION  SUPPORT 


Gerhard  W.  Albert 

Business  Man^^r 

Nancy  L.  Bryan 

Ed j tor 

Oeoorah  L.  Dunn 

Recept i on 

Patricia  A.  Hagedorn 

Secretary  to  Deputy  Director 

Rose  L.  Kattlove 

L  i  br  ar  i  an 

G.  Nelson  Lucas 

Graphic  Arts 

Mary  J.  WJnchell 

Business  Office 

Ruth  Wnlte 

Secretary  to  Director; 
Principal  Secretary 

CONTENTS 


Figures  iv 

Abstract  v 

Executive  Overview  vii 

1.  Automatic  Programming  1 

2.  Program  Verification  25 

3.  Programming  Research  Instrument  33 

4.  Protection  Analysis  43 

5.  Command  and  Control  Message  Processing  Technology  55 

6.  Information  Automation  65 

7.  Network  Secure  Speech  83 

8.  Technology  Support  89 

9.  Network  Management  Information  Center  97 

10,  Research  Resources  107 

II.  Programmed  Automation  115 

Co  I  I oqu i a  117 

Publications  120 

Doctoral  Theses  in  Progress  121 


i 


F  I  G  UR  £  S 


F  i  gu  r  e 

1.1  System  architecture  12 

1.2  NSto  hardware  22 

2.1  Decompos i t i on  of  the  verification  task  28 

2.2  Overall  organization  of  currently  running 

verification  system  29 

2.3  Outputs  from  components  of  program  design  and 

verification  system  30 

3.  1  The  MLP-900  34 

3.2  Basic  PRIM  con f I gur at  I  on  34 

3.3  MLP-900  conf  I  gurat.  ion  35 

3.4  Basic  PRIM  software  architecture  37 

4.1  Security  encapsulation  unit  46 

4.2  Representat ional  hierarchy  47 

4.3  IPd  evaluation  scheme  48 

4.4  error-driven  evaluation  process  52 

5. 1  Abbreviated  block  diagram  of  proposed 

communi cat  Ion  system  architecture  58 

8.1  The  ISI  portable  terminal  93 

10. 1  ISI  research  resources  facility  108 

10.2  I/O  bus  switch  109 


IV 


AbST  K  AC  T 


This  report  summarizes  the  research  performed  t>y 
u^C/ Inf or  mat i on  Sciences  Institute  from  17  May  1973  to  jfo 
May  1974.  Ihe  research  is  aimed  at  applying  computer 
science  and  technology  to  problem  areas  of  high  OoO/military 
1 mpac  t . 

The  ISI  program  consists  of  ten  research  areas  '• 
Automat  j  c  Pr ogr a mmi  ng-  the  study  of  acquiring  anc  using 
problem  knowledge  for  program  generation;  Progr  am 
Ver i f i ca t i on-  logical  proof  of  program  validity;  Progr  ammi ng 
Kesear ch  Instrument  -  development  of  a  major  time-shared 
mi croprogrammi ng  facility;  Prot  ec  t i on  Analysis-  methods  of 
assessing  the  vi abi iity  of  security  mechani sms  of  operatin  j 
systems;  Command  and  Con t  ro 1  Mess  age  Process i ng  ?  echno i ogy - 
tne  study  of  advanced  computer-based  techniques  for  military 
message  handling;  I  n  f  or  mat  i  on  Au  tomat  I  on-  development  _>f  a 
user -or i ented  messaqe  service  for  large-scale  military 
requirements’,  Net wor  k  Secure  Speech-  work  on  low -bandwi dth , 
secure  voice  transmission  using  an  asynchronous 
packet-switched  network;  [echno 1 ogy  Suppor  c -  development  of 
Xerox  Graphics  Printer  facilities  portable  terminals,  and 
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mi  Urary  office  termina'  system;  Network  Management 
1 nf or mat i on  Center  -  development  of  a  network  per  for  wance- 
measurement  methodology;  and  Research  Resources  -  operation 
of  TcNEX  service  and  continuing  development  of  advanced 
support  equipment.  Progr  e.mmed  Automat  i  on.  an  i  nves  t  i  gat  \  on 
of  the  feasibi ! I ty  of  a  computer-based  manufe  luring 


technology,  consisted  of  a  study  phase  only 


EXECUTIVE  OVERVIEW 


The  Information  Sciences  institute 
(ISl),  a  research  unit  of  the  University 
of  Southern  Ca I i forni a's  School  of 
engineering,  was  formed  Jri  May  1972  to  do 
research  In  the  fields  of  computer  and 
communi cat i ons  sciences  with  an  emphasis 
<■>.'  systems  anJ  app i ; c at i ons .  The  Insti¬ 
tute,  located  off-campus,  has  sufficient 
autonomy  wit  .In  tie  Univtrsity  structure 
' n  assure  i:  the  freedom  requi red  to 
i  ,}*-'■  tJ  fy  and  engage  In  significant 
research  programs. 

A  close  relationship  is  maintained 
vi tn  0-C  academ. "  programs  through  active 
cooper  at i < "  among  tne  Institute,  the 
school  of  Engineering,  the  Department  of 
Electrical  Eng  nuerlm,  and  the  Computer 
Science  Uepa:  roei.t.  Ph.D.  thesis  super¬ 
vision  Is  an  integral  par’  of  IS  I 
programs.  Also,  par 1 1 ci pat  1 ng  fatult'  and 
graduate  students  from  other  departments 
provide  interdisciplinary  capabilities  for 
Ij-I  projects. 

At  the  end  of  the  second  year  of 
operation,  the  full-time  professional 


research  staff  numbers  32.  The  total 
number  of  IS  I  employees,  including 
full-time  research  staff,  par t I ci pat i ng 
facult. y  and  g»  aduate  students,  and  support 
pe r sonne  1  ,  is  80. 

The  activities  of  ISl's  eight  major 
are  :«s  of  research  and  associated  support 
projects  are  summarized  briefly  below, 
iome  of  the  research  projects  reported  in 
this  document  are  discrete  activities  in 
themselves;  others  can  be  seen  as  parts  of 
a  larger  whole.  For  example.  Automatic 
Prcqr ammi ng.  Program  Ver J f i cat  I  on ,  and  the 
Programming  Research  Instrument  projects 
should  be  considered  as  Individual  parts 
of  an  overall  rese jrch  effort  in  Program- 
mi  ng  Methodology;  Command  and  Control 
Message  Processing  Technology,  information 
Automation,  Network  Secure  Speech,  arid 
Technology  Support  are  jinked  elements  of 
a  major  Investigation  into  Network 
Communication.  Technology,  These  mutual 
1  nr pr depe»oenc i es  among  the  various 
projects  at  1 S {  contribute  largely  to  the 
fruitfulness  ov  the  I  ns  cl  cute":;  research 
ac t i v 1  ties. 
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AUTOMATIC  PROGRAMMING 

The  Automatic  Programming  project  Is 
composed  of  three  .nain  activities*  first, 
the  design  and  preliminary  J mp 1 ement at i on 
of  an  automatic  programming  system; 
second,  the  i mp I ement at i on  of  a  Program¬ 
mer  'z  Interface,  a  I anguage-1 ndependent 


I  nter  face 

between 

a 

progr  ammer 

and  his 

1  anguagt* ; 

and  third 

,  the  1 

1  ni 1 1  at  ion  (in 

copper  at  ion  with 

ARP A)  of 

the 

Nat i ona 1 

Sof ;ware 

Wor  ks  , 

an 

ef  for  t 

to 

trans  f er 

technology  for  progran  development  to 
military  commands. 

rhe  automatic  programming  system  rep¬ 
resents  a  major  attempt  to  ded  directly 
with  nonprof ess  I ona  computer  users 
without  the  intervention  of  computer 
programmers.  " le  primary  goal  of  the 
system  is  to  acqui re  from  a  dialogue  with 
the  user  the  elements  of  the  probiem 
jomain,  then  translate  the  ill-defined 
speci  f  I  cat  I  ons  *~t.o  a  precise  form  and 
write  a  program  to  accomplish  the  user's 
desired  task.  An  initK  automatic 
i  roqr  amrni  rg  system  and  tne  associative 
data  Dase  mechanisms  it  relies  on  have 
been  implemented,  and  it  has  been  used  in 
turn  to  implement  an  initial  version  of 
tha  Model  Completion  phase.  Th*s  version 
is  able  to  take  carefully  selected  small, 
simple  domain  and  problem  statements  of  an 


Imprecise  form  and  convert  them  to  running 
programs  by  performing  a  series  of 
structuring  and  program  building  trans¬ 
formations  that  reorder  the  arguments  of 
relations  and  actions,  convert  the 
arguments  to  tne  coi rect  type,  and  fi II  in 
omi  ss  i  „*n s  . 

The  P, ograminer  's  Interface  effort 
addresses  the  general  problem  of  creating 
a  suitable  on-line  environment  for  pro¬ 
gramming.  It  attempts  to  exploit  the 

observable  uniformity  among  programming 
environment  systems  by  creating  a  single 
proqrammlnq  environment  capable  of  ea si ly 
interfacing  users  to  a  variety  of  on-line 
programming  languages.  With  minimal  cost 
and  effort,  the  Programmer ' s  Interface 
thus  transforms  a  programmer's  language 
into  a  programming  system  with  powerful 
debugging,  editing,  and  filing  ~apa- 
biiities.  The  first  such  Programmer's 

interface  has  been  constructed  and 

interfaced  to  the  programming  language 
ECL.  it  was  implemented  and  debugged  in 
appr  ox  i  mat  e  I  y  three  weeks,  including  the 
interface  to  lCL.  Although  no  otner 
language  interfaces  have  yet  been  built. 


it  is  es  t i mateo 

that 

an 

i nter  face 

to 

another  su i t  ab 1 e 

1  anguagt 

c  ou  1  d 

be 

designed,  implemented. 

and 

debugged 

I  n 

less  than  a  week. 
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The  concept  of  the  National  Software 
works  arose  from  the  realization  that 
serious  progress  In  '..proving  the  pro¬ 
duction  of  large  programs  would  be  made 
only  as  the  result  of  a  major  attempt  to 
improve  general  access  to  tools,  central¬ 
izing  the  management  of  a  vast  inventory 
of  currently  existing  hardware  and 
software,  Jo  do  this,  it  is  proposed  to 
link  tne  great  variety  of  tools  now 
available  on  the  ARPANET  into  a  coherent 
system  for  software  development,  employing 
a  standard  interface  for  users  and  a  very 
large  secondary  memory  for  storing  and 
managi ng  user  files.  IS]  was  instru¬ 
mental  in  the  system  design  and  functions 
as  technical  project  engineer. 

PROGRAM  VERIFICATION 

The  verification  of  a  computer 
program  Is  the  demonstr at  ion  by  a  mathe¬ 
matical  proof  of  the  consistency  between 
the  program  and  its  sped f I  cation  or 
documentation.  Program  verification  can 
greatly  increase  the  reliability  of 
software  by  assuring  that  programs 
actually  do  what  they  are  intended  to  do. 
The  large  amount  of  time  and  effort  now 
devoted  to  testing  activities  can  be 
significantly  decreased  by  verlfl  ration 
procedures,  which  will  ultimately  reduce 
software  costs.  Program  veri float. on  can 


also  have  an  influence  on  the  design  of 
programming  languages  and  can  serve  to 
test  advances  in  both  programming  method¬ 
ology  and  the  semantic  definition  of 
programming  languages. 

In  addition  to  experimenting  with 
new  specification  languages,  structuring 
methods,  and  proof  methods,  the  Program 
Verification  project  is  building  software 
tools  that  wi 11  aid  In  the  design  and 
construction  cf  verified  programs. 
Verification  condition  generators  for  two 
programming  languages  are  already  in 
operation?  algebraic  simplification  and 
Interactive  proving  of  the  lemmas  produced 
oy  the  verification  condition  generator 
are  /iso  being  accomp I i shed.  Current 
plans  are  to  deve’-n  these  components 
into  a  smoothly  integrated  system  whose 
capabi l i t I cs  can  be  demonstrated  on 
significant,  re^l  programs. 

PROGRAMMING  RESEARCH  1 HS 7 

The  Programmina  Research  Instrument 
(PRIM)  project  has  created  a  fully 
protected  experimental  computing  environ¬ 
ment  w’th  continuous  multiuser  access.  An 
ARPANET-based  system,  PRIM  aiiows  each 
©searcher  to  create  his  own  specialized 
computing  engine  capable  of  being  changed 
and  adapted  to  his  specific  needs.  The 
PRIM  hardware  and  software  together 
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provide  a  working  env i  rcnment  in  which  the 
user  can  implement  his  own  computer  in 
microcode  and  run  that  computer  in  his 
target  program  environment.  PRIM  can  be 
usea  to  explore  computer  ar ch 1 tectur e , 
language  development,  and  sped  a  1 -pu 'pose 
processor  design  —  all  of  especial  rel¬ 
evance  to  DoD  selection  «*nd  use  of 
computer  equipment. 

The  PR1 M  facility  makes  it  possible 
to  simulate  new  hardwa  e  -,rch  i  tec  .ures  and 
designs  :r  ml croprogr ammeu  software.  That 
is,  software  can  be  created  for  hardware 
nc  yet  available,  and  hardware  designs 
may  be  extensively  used  and  changed  *>ven 
before  the  piototype  stage  of  development 
is  reached,  whic.  should  both  cut  lead 
time  end  in  ove  decisions  connected  with 
the  special-purpose  machine  procurement 
cycle. 

At  present,  most  ml croprogr ammed 
processors  operate  t  o  a  single  u*  ' 
environment,  with  a  minimal  operating 
system  and  a  single  application.  Tr.» 
particular  value  of  the  PRIM  project  and 
Its  Introduction  of  a  ml  vorogr  ammed 
supervisor  (microvisor)  state  has  been  to 
make  an  easily  accessed,  sharable, 
powerful  design  tool  for  the  .computer 
development  community. 


To  familarize  potential  users  with 
the  operation  of  the  PRIM  system,  lb!  will 
provide  I ntroductory  seminars  and  an 
extensive  document  at i on  package  PRIM 
user  documentation,  consisting  of  an  Over¬ 
view,  User's  Guide,  ML P-900  Reference 
Manual,  and  GPM  Reference  Manua ! ,  is 
nearing  completion  and  should  be  available 
to  Interested  potential  users  by  mid-197A. 

PROTECT! JN  ANAUTSJS 

The  Protection  ^nalysi'  project  has 
cove  loped  and  is  continuing  to  refine 
techni”  es  and  standards  for  testing  and 
evaluating  the  protection  features  of 
operating  systems.  Its  goal  Is  to  p, ovide 
answers  to  the  question  c.:  what  tests  can 
and  should  be  apolied  tc  c^eratlng  systems 
in  order  to  determine  to  what  extent  a 
given  system  meet'  Its  requ I rement s  for 
preventing  unauthorized  or  improper  opera¬ 
tions  and  how  systems  can  best  be 
designed  and  implemented  to  reflect  such 
r ecu  1 rement s .  The  research  directly 
supports  the  software  security  require¬ 
ments  Issued  by  CoO  security  po 1 1 cymakl  ng 
agcncl es. 

Ourlng  the  last  reporting  period, 
what  is  now  the  Protection  Analysis  pro¬ 
ject  was  designated  as  the  Empirical 
System  Stu~«y  and  Protection  Theory 
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projects.  These  projects  merged  to  study 
ways  of  applying  empirical  techniques 
toward  achieving  a  "production*  evaluation 
tool.  Th*  study  was  influenced  by  the 
observat.ons  that  the  security  community 
lacks  a  production  evaluation  tool;  that 
there  Is  currently  no  known  organized 
effort  vO  collect  and  analyze  protection 
errors  *  and  that  such  errors  do  fall  Into 
distinct  classes  or  "patterns.*  The  study 
focuses  on  the  way  in  which  the  output  of 
protection  evaluations  (i.e.,  errors  and 
their  patterns)  can  be  utilized  as 
feedDack  in  tne  development  and  invove- 
ment  of  an  evaluation  method  itself.  The 
result  Is  the  design  of  a  systematized 
patter n-dr i ven  evaluation  scheme  that 
utilizes  the  output  of  error  analysis  both 
directly,  to  govern  the  evaluation 
process,  and  indirectly,  to  increase  the 
comprehensiveness  of  the  tool  based  on 
tnis  metnod.  The  Empirical  System  Study 
group  also  devised  a  simple,  economical, 
and  reliable  approach  to  the  security 
retrofit  problem  for  batch  and  remote  job 
entry  systems,  termed  encapsu 1  at i on . 

COMMAND  ANO  CONTROL  Mt SSAGE  PROCESSING 
technology 

Inis  project  explores  the  use  of 
advanced  computer  and  communication  tech- 
ni  t*es  in  military  environments.  The 


implementation  of  an  automatic  message 
handling  service  on  a  packet -sw I tched 
dlqital  network  (exemplified  by  the 
ARPANET)  has  immediate  ana  significant 
usefulness  to  the  mJlitary  commjnity.  The 
possible  applications  of  such  a  service 
have  served  as  the  principal  focus  of  the 
work  to  date. 

A  specific  example  of  such  an 
environment  was  the  object  of  a  study 
performed  oy  ISI  in  the  spring  of  1973  to 
investigate  the  possible  application  of 
network  technology  to  the  COTCO  (Consol- 
i dat i on  of  T ei ecommunJ cat i ons  on  Oahu) 
program,  a  OoU  effort  to  Improve  military 
common  I  cat i ons  on  Oahu. 

The  Navy,  vhicn  has  been  assinred  the 
tabfc  of  implementing  the  OICG  program, 
currently  r.as  the  I S  2  plan  under  consider¬ 
ation.  Interest  nas  been  expressed  In 

performing,  with  the  cooperation  of  ARPA, 
a  test  of  an  interactive  system  such  as 
the  one  proposed. 

In  the  meantime,  the  Command  and 
Control  Message  Processing  Technology 

(CCMPT)  project  has  addressed  the  issues 
involved  in  the  implementation  of  auto¬ 
mated  message  hand  I  I ng  services  for  other 
military  environments  besides  COTCO.  In 

order  to  achieve  the  sort  of  system 
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envisioned.  It  is  necessary  to  piovide  tne 
following  Das  I c  components  and  attributes^ 

*  Core-system  hardware  architecture  that 

serves  as  the  foundation  for  building 
the  service. 

■  Core-system  software  architecture  and 

programs  whose  facilities  are  easy  to 
learn  and  operate  by  users  unfamiliar 
wi th  computers. 

■  Applicati  .>n  software  that  performs  the 

functions  required, 

■  Reliability  of  service. 

*  Security  of  data. 

The  CCMPI  project  is  currently  in  a 
study  pnase,  identifying  the  problems  and 
the  opportunities  for  message  processing 
In  the  military  environment.  The  program 
outlining  detailed  areas  for  research  is 
now  being  prepared.  in  addition,  we  are 
exploring  opportunities  for  joint  bevel  * 
opment  with  military  use's  tnat  will  apply 
our  message  technology  In  exper J ment a  I 
form  to  actual  military  situations. 

INFGRMaT  I  ON  AUTOMATION 

The  Information  Automation  project  is 
currently  in  the  design  phase  of  a  tele¬ 
communications  task  conceived  to  aid  the 


military  and  users  of  the  ARPANET.  The 
goal  Is  to  Implement  an  on-line  message- 
handling  system  (the  core  of  the  Command 
and  Control  Message  Processing  Technology 
Project  above),  which  will  be  usable  by 
people  unfamiliar  with  computers.  The 
initial  study  for  Lhis  task  investigated 
the  user  styie  and  functional  require¬ 
ments  of  a  large  muitiservice  military 
community.  The  functional  spec i f i cat i ons 
for  tnis  system  incluae  message  prepa. - 
at i on  (creation,  editing,  coor d l nat i on) , 
message  transmission  f routing,  release, 
status  query).  and  message  oo  13  very 
(priority,  delivery,  sorting,  scanni ng, 
forwarding).  Additionally,  the  system 
will  support  off-line  report  generation 
and  message  archives.  The  research  goal 
of  the  Information  Automation  project  is 
to  develop  the  necessary  human- factors 
methodology  needed  to  introduce  Inter¬ 
active  computer  terminals  into  office 
environments.  The  project  thesis  is  that 
current  systems  technology  will  suffice 
for  many  of  the  current  automatable 
problems  and  that  what  is  required  is  a 
collection  of  techniques  to  make  the 
computer  acceptable  arid  useful  to  non¬ 
technical  personnel.  The  target  system 
wii;  be  implemented  at  IS1  on  TENEX  and 
the  ARPANET.  It  is  expected  that  an 
experimental  system  providing  the  above 
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functions  will  be  available  to  ARPANET 
users  ear  I y  I n  I  975. 

Nl  T rtJRK  SECURE  SPccCH 

In  response  to  the  hign  military 
priority  of  developing  a  digital  means  #or 
secure  speech  transmi ssi on,  the  ISI  Net¬ 
work  secure  Speech  project  Is  attempting 
to  establish  the  means  to  us*  a  packet- 
switching  network  (the  ARPANET)  for 
secure,  high-quality,  real-time,  full- 
duplex  voice  communication.  The  resulting 
voice  commu ni cat  i  ons  system  wi  II  have  the 
following  advantages*  it  will  oe  able  to 
De  secured  (encrypted)  to  an*  desired 
Jewel  of  complexity  and  security;  It  will 
De  able  tc  achieve  extremely  high  quality 
transmission  with  a  low  error  rate;  it 
w 1  11  exploit  the  natural  pauses  and  breaks 
In  human  speech  to  achieve  a  lower  overall 
data  rate;  it  will  oe  highly  compatible 
with  future  communications  systems  (satel¬ 
lites,  lasers,  etc.).  The  project's  major 
goal  is  to  establish  the  methodology  of 
using  the  ARPANET  for  communlcr  ion  and  to 
i  element  It  with  real-time  bandwidth 
compression  (vocoding)  as  a  proof  of  feas¬ 
ibility,  Present  efforts  are  to  perform 
network  measurements  for  the  development 
of  the  required  protocols  and  to  implement 
the  chosen  vocoding  technique;  future 


plans  are  to  optimise  the  communication! 
protocols  and  to  improve  the  quality  an< 
reduce  ihe  bandwidth  of  the  vocodl n< 
t  eenni que. 

TECHNOLOGY  SUPPORT 

The  lechnoiogy  Support  sect! or 
describes  three  of  the  major  advanced 
hardware  systems  being  developed  at  ISI* 
the  enhancement  of  a  Xerox  Graphics 
Printer  system  to  produce  a  high-quality 
aocument  printing  capability  in  the  form 
of  a  network  terminal;  a  video  display 
system;  and  a  or i e f case-s i 2ed  portable 
terminal  designed  for  use  with  the 
ARPANET,  Each  of  these  hardware  efforts 
was  undertaken  either  to  demonstrate  a 
capability  for  a  recognl2ed  OoO  appli¬ 
cation  or  to  provide  the  necessary  support 
for  the  several  software  projects  tnat 
compose  the  Network  Communications  Tech¬ 
nology  effort  (Command  and  Control  Message 
Processing  Technology.  Information  Auto¬ 
mation,  and  Network  Secure  Speech). 

NETWORK  MANAGEMENT  I NTQRMA7 ION  CENTER 

Computer  networks  service  a  highly 
heterogeneous  user  population,  possess  a 
complex  structure  of  hardware  and  soft¬ 
ware,  and  require  careful  arbitration  of 
the  potential  conflicts  among  users. 
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hosts,  and  the  network  budget ,  The  need 
for  a  performance  measurement  methcdoloqy 
is  great ,  particularly  because  of  the 
dynamic  ,hort-  ara  long-term  variations  in 
net  wor k  wcf  k 1 oao. 

I  he  Network  Management  information 
Center  ( NM  IC)  at  I  Si,  launched  in  March 
197^,  will  provide  an  effective  means  for 
resolving  t echnc I ogi ca 1  issues  in  net* or k 
performance  by  developing  a  r epor t/dl sp 1  ay 
capability  that  will  furnish  information 
on  network  status  and  operations  as  well 
as  providing  an  alternatives  assessment 
capability  that  will  permit  rapid  man¬ 
agement  assessment  of  the  relative 
desirability  of  network  alterations  and 
ennancements . 

Achieving  the  capabilities  described 
above  requires  accurate  knowledge  of 
network/subnetwork  status  and  performance. 
Thus,  the  nitial  focus  of  the  project 
wi  II  oe  to  establish  an  alternate  Net¬ 
work  Control  Center  (NCC)  which  wi  11 
(1)  provide  a  scheduled  backup  capability 
to  the  existinq  NCC  at  BBN,  (2)  develop 
operating  policies  and  procedures  for 
concurrent  cooperative  operation  of 
multiple  NCC's,  thus  assuring  the  integ¬ 
rity  of  the  network  in  the  event  of  an 
NCC  outage,  and  (3)  develop  requirements 
and  objectives  for  a  minimum-manpower 


iri  nl  mum-sKi  I  I  -  leve  I  NCC,  tnus  clearly 
separating  the  roles  of  equipment  vendor 
ana  operations. 

NM1C  will  oe  of  direct  use  to  a  1  l  DoD 
and  domestic  agencies  concerned  with  the 
design  and  implementation  of  computer 
networks.  Since  it  wl  l  I  provide  a  cen¬ 
tralized  means  for  data  reduction  and 
t rans for  mat i on  into  forms  permitting 
cirect  !  *uer  pr  etat  I  jn  by  management ,  this 
research  wi  li  ’Iso  constitute  a  perfor¬ 
mance-ana  I  y  s  i  s  capability  of  direct 
interest  to  agencies  dealing  with 
sensitive  mat er i a  1 --agenc i es  traoi t i cna  I  !  y 
unable  tc  gain  full  use  of  performance 
tools  and  consultants  because  of  the 
sensitive  nature  of  their  job  stream.  In 
addition,  the  research  will  also  be  oc 
direct  benefit  to  ARPA/1P7Q  in  managing 
the  ARPANET,  since  on-line  performance 
information  maintained  at  NMIC  will 
provide  a  centralized  access  point  for  all 
network  performance  Information  for  use  Jn 
management  decisionmaking. 

PROGRAMMED  AUTOMATION 

From  July  1973  to  December  1973  the 
Programmed  Automation  project  evaluated 
tne  feasibility  of  various  advancements  In 
cc mpu ter -based  manu f actur I ng  systems, 
evaluated  the  economic  impact  on  the  U.S, 
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economy  and  the  OoO  from  Implementing 
those  advances,  and  defined  the  specific 
development  program  and  resources  required 
to  achieve  them.  This  project  consisted 
cf  a  study  phase  only,  and  further  work 
has  since  Deer,  discontinued. 

RESEARCH  RESOURCES 

The  ISI  time-sharing  facility, 
operatea  as  a  research  and  service  center 
in  support  of  a  Droad  set  of  ARPA 
projects,  consists  of  two  PDP-IO  CPUs, 
paqi ng  oox ,  I ar qe-capaci ty  memory,  nigh- 
performance  paging  drum,  on- i ire  file 
stcraqe,  a~d  associated  peripherals.  The 
hardware  acauired  in  the  past  year  as  part 
cf  tne  general  effort  to  improve  system 
avai I aoi I i ty ,  capacity,  and  efficiency  in¬ 
cludes  a  second  PO P-10  CPU,  an  additional 
J  28K  of  high-speed  memory,  six  disk  drives 
that  will  approxi mate  I y  aouble  the  present 
on-line  file  storage,  and  several  inter¬ 
faces  and  switches  designed  and  built  at 
ISI  . 


In  an  effort  to  reduce  system  load,  a 
group  allocation  scheme  was  introduced  in 
March.  This  scheme  divides  the  total 
number  of  available  job  slots  Into 
genera  I -access  and  limited-access  cate¬ 
gories,  with  each  type  further  subdivided 
into  groups  assigned  a  quota  (varying  in 
size  throughout  the  day)  specifying  how 
many  group  members  wi II  pe  guaranteed 
access  to  the  system.  Group  members  whose 
group  quota  is  f! lied  can  log  in  off-quota 
to  fill  other  slots  not  in  use  at  the 
time.  /men  the  system's  totai  available 
quota  is  set  to  a  sufficiently  low  level, 
the  system  is  responsive  and  effective  to 
those  allowed  to  log  on.  In  all,  the 
initial  experience  with  group  allocation 
has  Deen  geod. 

The  report  that  follows  presents  a 
detailed  view  of  the  goals  and  accomplish¬ 
ments  of  the  many  di fferent  areas  of  ISI 
research  durlnq  the  Institute's  second 
year  of  operation. 
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INTRODUCTION 

As  reported  last  year,  work  in  the 
Automatic  F-roorammi  nn  (AP)  c*' eject  has 
centered  upon  three  main  activities. 
First,  we  have  desinned  an-'  beeurt  to 
implement  an  automatic  proqrarrari nq  system. 
Functionally,  the  two  most  important 
characteristics  of  this  s>  tern  are  its 
independence  from,  any  particular  problem 
domain  and  its  attempt  to  deal  directly 
with  nonprof ess i ona i  computer  users 
without  the  intervention  of  computer 
proarammer s .  These  choices  have  larqclv 
dictated  the  direction  of  the  project. 
Domain  i ndependence  requires  that  the 
"physics"  of  the  domain-- Its  objects  and 


Lnei r  relationships  with  other  objects, 
itr  lavs,  it  ,  trans  f  orrrat  i  ons  ,  ann  its 
constrai nts --be  available  in  a  processablc 
form  within  the  system  and  that  the  system 
be  neneral  er.ouoh  tr  deal  effectively  v  i  t  Fi 
a  side  variety  of  such  physics.  Direct 
interao.tior  with  r.onj  rof  os  si  ona  !  computer 
users  means  that  both  the  physics  and  the 
problem  statements  vi  II  be  i  r.  problem- 
oricrited  (as  opposed  tr  computer-oriented) 
terns,  preferably  in  natural  I  arena oe,  ann 
that  they  will  be  "Nkjcc"  oesca  i  pt  i  ons 
contain! no  incomplete,  inconsistent,  anc 
irrelevant  statements  rather  than  a 
precise  formal  structure.  i  he  primary 
qoa  l  of  the  system,  is  to  acquire  from  a 
dialogue  with  the  user  the  snysics  of  the 
loosely  defined  dor-ain,  structure  it,  arm 
use  it  to  understand  further  comrruri  cat!  on 


1 


Inpuduc  f  I  on 


r ind  write  a  program  10  accomplish  the 
t^.or  S  s t a t e f !  ItVjk. 

Toward  this  end,  we  have  i  m, :  1  ement ecj 
an  associative  qnta  base  in  which  tc  store 
the  r lilts,  objects,  and  relations  of  a 
nomain  and  have  i ntecratcd  into  L I  Sr  a 
pattern  match  facility  to  access  the  items 
stored.  Using  this  facility  we  have  also 
implemented  a  prel ini  nary  version  of  our 
system's  structuring  portion,  called  Model 
Completion,  which  is  ab'e  to  structure  and 
convert  to  executable  form  simple  small 
domain  and  problem  descriptions.  The 
other  major  component  of  our  system. 
Domain  Acquisition,  which  will  acquire  the 
loose  model  of  the  domain,  is  still  in  the 
planning  star,e;  we  are  at  present 
simulating  its  behavior  in  scenarios  to 
1  a rn  more  about  how  it  should  perform. 
During  this  next  year,  we  expect  to 
implement  an  initial  version  of  Domain 
Acquisition,  achieve  a  complete  running 
system,  and  concentrate  on  extending  both 
the  capabilities  of  each  phase  and  the 
system's  ability  to  deal  with  domains  of 
significant  size  and  complexity. 

Second,  we  have  completed  work  on  a 
1  arinuage-  f  ndependent  interface  between  a 
programmer  and  his  lamuage,  called 
the  Programmer's  Interface  (PI),  which 


transforms  his  language  into  a  urooraiwii  nq 
system  with  almost  all  of  the  capabilities 
of  the  I A  TL^ LISP  (formerly  iiPN-LiSP) 
system:  powerful  debugging,  editing,  and 

filing  capabilities,  as  well  as  the 
ability  tc  moo'fv,  croup,  and  reissue 
previous  commands.  This  work  is 

significant  at  two  levels.  first,  it. 

provides  a  very  quirk  and  inexpensive  way 
of  enhancing  the  programming  environment 
of  an  interactive  language.  Much  more 

importantly,  however,  it  demons trates  the 
relative  ianquaq*  independence  of  many  of 
the  tools  required  for  program  building 
and  de bn <iging. 

Ibis  recognition  led  directly  to  the 
initiation,  in  cooperation  with  ARPA,  of 
our  third  area  of  involvement,  the 
National  Software  Works  (NSW).  This  i  a 
major  new  ARPA  project  to  transfer 
technology  for  program  development  to 
military  commands  within  DoD.  Because  the 
Initial  NSW  is  planned  for  test 

Installation  in  July  197S,  its  scope  is 
deliberately  limited  to  make  this  early 
delivery  feasible.  Nevertheless,  it 
incorporates  many  advanced  concepts  and  is 
explicitly  deslqned  for  expi.oi on.  It 
significantly  e. tends  the  PI  concept  by 
separating  the  tools  used  for  proqrammi ng 
from  those  used  for  program  execution. 
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The  NSW  provides  a  framework  that,  controls 
the  access  to  and  use  of  tools  through  a 
standard  user  interface  and  enables  new 
tools  to  be  easily  added.  Because  these 
tools  can  exist  on  different  machines,  the 
framework  acts  as  an  operation  system  by 
making  the  use  of  a  tool  independent  of 
its  location;  it  automatically  initiates 
tho  tcol,  establishes  communication  with 
it,  transfers  necessary  files  for  its  use, 
and  saves  any  output  generated.  The  NSW 
thus  ties  together  tools  that  exist 
anywhere  on.  the  ARPANET  into  a  coherent 
system  for  software  development.  Part  of 
the  NSW  is  a  user  interface  tnat 
standard! zes  the  way  in  which  users 
initiate  a  tool,  communi cate  with  it,  ask 
for  help,  or  exnni ne  their  output.  Tne 
final  component  is  a  very  large  secondary 
memory  for  the  storage  and  management  of 
user  fi les. 

In  addition  to  these  components  of 
the  NSW,  which  merely  provide  a  convenient 
home  for  tools  and  which  enable  users  to 
uniformly  access  and  communicate  with 
them,  the  tools  themselves  exist, 
determining  the  system's  capabilities  to 
affect  software  development.  These  tools 
are  divided  into  two  categories: 
(1)  "centralized"  tools,  like  editors, 
flowcharters,  test  case  generators,  etc.. 


which  art  independent  of  the  target 
machine  on  which  the  program  being 
developed  is  to  run  whi le  in  production 
mode  arid  which  therefore  only  require 
implementation  on  a  single  machine,  and 
( ^ )  executior  machine  tools,  like 
compilers  ano  run-time  moni tors,  which 
actually  run  on  the  target  machine  and 
which  ’’ust  be  r  c-  i  mp  I  enented  or,  each 
target  machine. 

AU I  ON A 7 1 C  PA06A AMnl NG  ifr G* 1 

After  an  initial  survey  of  current 
work  I n  the  field,  the  AP  project  members 
developed  a  rlan  for  attacking  what 
appeared  to  be  the  fundamental  issues  of 
automatic  programming.  This  took  the  form 


of  an  actual 

!  system. 

the 

desi gr 

and 

i mo  1 ementat i on 

of  which 

is 

now  |  n 

i  ts 

early  stages.  The  results  of  the  initial 
survey  ant!  the  overall  view  of  the  field 
adopted  are  reported  elsewhere  [l,2j.  It 
should  be  emphasized  that  this  project  is 
seen  not  as  an  incremental  advance  in 
computer  languages  or  the  art  of 
programming,  but  rather  as  an  attempt  to 
make  the  power  of  the  computer  available 
to  a  large  class  of  users  without  the 
necessity  of  a  step  like  that  now  called 
programmi no.  Ultimately,  a  client  should 
be  able  to  negotiate  directly  with  a 
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computer  system  In  much  the  same  way  as  he 
now  negotiates  with  a  programmer . 

Computer  use  generally  falls  into  two 
categories:  use  of  existing  programs  or 
creation  of  new  ones.  There  is  no  sharp 
distinction  between  the  two,  because  data 
fed  into  existing  programs  can  be  thouaht 
of  as  instructions  that  program  their 
behavior  and  because  the  creation  of  new 
programs  utilizes  either  compilers  or 
interpreters  that  treat  such  instructions 
as  data.  Also,  the  techniques  for  trans¬ 
lating  a  task  into  appropriate  input  for 
the  two  are  very  similar.  Nevertheless, 
we  have  chosen  to  deal  only  with 
nrocramming  .activities,  which  we  regard  as 
the  process  of  translating  a  task  to  be 
performed  into  a  computer  langunqe,  taking 
into  account  the  constraints  and  limi¬ 
tations  of  both  the  computer  and  the 
domai n  of  interest  from  which  the  task  was 
drawn. 

The  constraints  and  restrictions  of 
the  computer  have  increasingly  been 
incorporated  and  internalized  in  pro¬ 
gramming  advances  for  several  years.  They 
are  manifest  in  better  languages, 
automatic  storage  mechanisms,  and  optimi¬ 
zations  of  many  forms.  On  the  other 
hand  the  structure,  constraints,  and 


limitations  of  the  problem  domain  have 
generally  not  been  i ncorporated  Into 
programming  systems.  The  use  of  such 
knowledge  is  a  major  theme  of  auto¬ 
matic  programming,  char acter i zi ng  the 
distinction  between  it  and  conventional 
programmi ng,  and  rai ses  j  number  of 
issues.  If  the  system  is  to  understand 
something  of  a  domain — a  particular 
universe  of  discourse — how  is  the 
knowledge  on  which  this  under stanai ng  is 
based  to  be  represented?  What  procedures 
can  be  made  available  for  exploiting  this 
knowledge  in  guiding  the  system's  inter¬ 
action  with  a  user  and  in  generating 
programs?  How,  in  particular,  is  the 
essentially  nonprccedur a  I  information  in 
constraints  and  limitations  to  be 
reflected  in  a  procedural  form?  What  can 
be  done  to  help  identify  inconsistencies? 
How  cat.  *"he  system,  be  given  a  capacity  for 
inference  similar  to  that  which  forms  the 
mainstay  of  human  communication  and  which 
allows  obvious  details  to  be  left 
unspecified?  Will  the  system  be  able  to 
understanci  its  own  products  well  enough  to 
be  able  to  modify  them  in  response  to 
changed  requirements?  Answers  to  these 
questions  define  the  front  on  which 
important  advances  In  automatic  pro- 
gramminn  will  be  made. 
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The  designers  of  programed  nci  systems 
have  until  now  concentrated  their 
attention  on  creating  Instruments  that 
would  be  easy  to  play.  Like  all 
instruments,  the  system  had  a  purely 
passive  role  in  the  programed  ng  enter¬ 
prise.  We,  on  the  other  hand,  took 
the  view  that  the  problem  of  programming 
is  largely  a  problem  of  communication  and 
that  communication,  to  be  easy  and 
neural,  must  be  with  an  active  agent. 

Thus  the  main  distinction  between 
conventional  and  automatic  programming  is 
the  latter 's  use  of  a  semantic  model  of  a 
domain  to  structure  the  dialooue  between 
the  system  and  the  user,  to  understand  the 
user's  responses,  and  to  translate  the 
user's  responses  into  actions.  The  major 
distinctions  between  the  work  reported 
here  and  other  automatic  f rogrammi nq 
efforts  are  the  following;  first,  its 
independence  of  any  particular  domain  end 
its  acquisition  of  the  domain  model 
through  a  dialogue  with  the  user;  and 
second,  the  informal  and  typically 
i  1  I -structured  manner  in  which  both  the 
domain  semantics  and  the  task  to  be 
programmed  are  specified.  In  fact,  these 
two  areas  represent  the  two  main 
focuses  of  the  project:  di alogue- dr t ven 
acquisition  of  a  domain  and  translation  of 


ill-defined  sptcl f i cati ons  into  a  precise 
form. 

Over a  i  i  System  Structure 

In  our  plan,  the  AP  system  consists 
of  four  processing  modules  and  six  data 
bases.  The  data  ba-.es  consist,  as  much  as 
possible,  of  descriptive  (rather  than 
imperative)  knowledge,  organized  so  that 
the  system  can  use  trds  knowledge  in  many 
different  ways.  These  data  bases  have 
been  segregated  because  of  the  different 
logical  functions  they  perform  and  because 
of  the  way  they  are  treated  by  the 
different  processing  modules. 

Data  Pases 

The  Domain  .<nowledne  data  base 
contains  all  the  descriptive  information 
about  the  problem  domain,  such  as  the 
types  of  objects  that  can  exist  in  the 
domain  and  their  descriptions,  the  types 
of  actions  that  can  occur  in  the  domai n, 
the  relations  tfat  may  exist  between 
objects  or  events  (action  occurrences), 
and  any  constraints  that  must  be  satisfied 
by  the  domain. 

1  he  Domain  Model  contains,  at  any 
point  in  time,  an  i ns tantaneous  snapshot 
of  the  i nstant i aled  objeccs  in  the  domain 
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and  their  relationship  to  other  objects  In 
the  domain.  It  represents,  through  t.me, 
a  direct  simulation  of  the  problem  domain. 

The  Loose  Mode’,  contains  the  problem 
statement  in  an  imprecise  form  that  may  be 
incomplete  or  ambiguous  and  that  can  be 
understood  only  in  the  context  of  the 
information  In  the  Domain  Knowledge  and 
Domain  Model  data  bases. 

The  Precise  Model,  on  the  other 
hand,  represents  a  precise,  complete, 
unambiguous,  and  directly  I nter pretab  I e 
process  for  solving  the  problem  posed. 

The  Strateny  Knowledge  data  ija;c 
consists  of  information  that  guides  the 
choice  of  actions  and/or  objects  for  those 
actions  when  alternative  possibilities 
exist  within  the  domain. 

Finally,  the  Script  data  base 
contains  par t i a  1 1 y- f i 1 1 ed' i n  forms  that 
guide  the  diaiooue  between  Che  system  and 
the  user  and  are  dynamically  altered  on 
the  basis  of  the  user's  input  and  by  the 
demands  of  the  Model  Completion  module. 

Process! nn  Modules 

Initially,  to  simplify  the 
implementation,  the  processing  modules 
will  be  highly  self-contained  and  will 


have  only  a  limited  knowledge  of  the 
processing  and  requirements  of  other 
modules.  Later  they  will  be  mere  highly 
integrated  and  cooperative. 

The  uomain  Acquisition  module  is 
responsible  for  communicating  with  the 
user,  building  the  Domain  Knowledge  and 
Domain  Model  data  bases,  obtaining  the 
Loose  Model  statement,  determining  on 
syntactic  grounds  the  well-formedness  of 
all  this  information,  building  and 
modifying  the  Script,  and  using  it  to 
direct  the  dialogue  for  the  acquisition  of 
further  information  necessary  for  such 
syntactic  we  1 1  - f orr edness  or  requested  by 
the  Model  Completion  module. 

The  Model  Completion  module  deter¬ 
mines  the  semantic  well-formedness  of 
the  Loose  Model  on  the  basis  of  the 
information  in  the  Domain  Knowledge  and 
Domain  Model  data  bases.  It  is 
responsible  for  transforming  the  Loose 
Model  Into  an  operational,  I nter pretab  I e 
form  called  the  Precise  Model.  Any 
inability  to  perform  this  transf ormatl on 
causes  a  description  of  the  reason  to  be 
passed  back  through  the  Script  to  the 
Domain  Acquisition  phase,  which  then 
interacts  with  the  user  to  correct  the 
deficiency  (usually  by  adding  more 


knowledge  about  the  domain  to  the  Domain 
Knowledge  data  base). 

The  Interpreter  executes  the  action 
sequences  Sn  the  Precise  Mcoei  and  updates 
the  Domain  Model  accordingly.  It  is 
responsible  Tor  locating  objects  defined 
descriptively,  evaluating  conditions  to 
select  alternative  sequences  of  actions, 
and  maintaining  restrictions  on  domain 
behavi or. 

T..e  Data  Base  Handler  is  responsible 
for  maintaining  the  various  data 
bases,  deciding  on  store-recompute  policy, 
maintaining  com  1 stency,  and  (through 
inference)  nhscuring  the  difference 
between  explicit  and  implicit  data. 

A  primary  objective  of  our  project 
has  been  to  create  a  core  experimental 
system  for  testing  progress  on  Domain 
Acquisition  and  Model  Completion.  As 
such,  the  Interpreter  and  Data  Base 
Handler,  which  have  been  completely 
specified  and  implemented,  are  being  used 
for  both  the  Precise  Model  and  the 
implementation  of  the  AP  system  itself. 
To  fully  utilize  these  implementation 
capabilities,  the  Domain  Acquisition  and 
Model  Completion  modules  will  be  treated 
as  domains  with  their  own  actions, 
objects,  constraints,  and  rules  of 
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inference.  Thus  bootstrappi  ng  will  focus 
attention  on  the  real  problems  of  using 
our  approach  In  complex  domains. 

A  more  detailed  description  of  the 
system  is  riven  in  the  to  I  lowing 
subsections,  which  focus  on  the 
r cpresentat i on  of  knowledge  and  the  form 
of  the  Precise  Mooel  produced  by  Model 
Comp  1 et i on. 


Knowl edc 


Throughout  the  system,  knowledge  is 
represented  as  stored  tuples.  The  first 
element  of  any  tuple  specifies  the  type  of 
tuple;  the  rest  of  the  elements  are  the 
arguments  for  that  tuple.  Each  stored 
tuple  is  associated  with  a  particular 
domain.  Data  bases  are  compar tmenta 1 i zed 
into  separate  domai ns  that  form  a  lattice. 
Each  domain  is  defined  as  A-KIND-OF  (Ai<0) 
another  domain;  this  structure  forms  the 
basis  of  the  domai n  lattice.  The 
Interpretation  of  the  lattice  structure  is 
that,  unless  specifically  prohibited, 
properties  (of  all  types)  from  higher 
level  domains  are  inherited  by  lower  level 
ones. 


The 

structure  of 

knowledge  in 

the 

system 

is 

hi gh 1 y 

constrained  by 

two 

rrcchani  s 

ms^ 

types  and 

constrai nts. 
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element  of  a  tuple  must  be  of  a  type 
acceptable  for  that  argument  as  specified 
In  the  definition  of  that  kind  of  tuple. 
Like  domains,  types  are  defined  by  AKO 
relation  and  form  lattice:'.  (Ihis 
structure  is  very  similar  t  APL  [3].)  An 
element  of  a  tupie  is  acceptable  if  its 
type  is  the  same  as  that  specified  in  the 
tuple  definition  or  if  its  type  is  a 
lattice  descendant  of  the  specified  type. 
In  addition  to  type  acceptability,  the 
elements  of  a  tuple  must  also  satisfy 
arbitrary  constraints  specified  in  the 
tuple  definition.  These  constraints  are 
checked  at  the  time  that  the  tuple  is 
added  to  a  domain. 


A  domain  consists  of  types  (objects), 
actions,  relations,  constraints,  rules  of 
inference,  and  i ns tant i a t i ons  of  all  of 
the  above.  Together  with  the  type  and 
constraint  mechanisms  for  tuples,  this 
knowledge  of  the  kinds  of  information 
contained  within  a  domain  represents  the 
syntactic  basis  used  by  the  Domain 
Acquisition  module  to  construct  and  modify 
its  Script,  and  hence  its  dialogue  with 
the  user. 


Pr eci se  Mode  1 

The  Precise  Mooel  is  the  restatement 


of  the  user's  problem  in  the  programming 
language  AP/ i  [4].  This  language  is  an 
extension  of  LISP  [5],  which  supports 
associative  relational  data  bases  with 
domain  comar  tmenta  1 1  zat  i  on,  strongly 
typed  variables,  compound  pattern  matches, 
and  failure  control.  Strong  typing  and 
compound  patterns  are  especially  important 
in  simplify! nr  the  system's  writing  of 
the  Precise  Model  by  minimizing  the 
translation  between  it  and  the  Loose  Model 
and  by  reducing  and  simplifying  the 
coitrol  structures  required.  In  fact, 
compound  patterns  have  enabled  the 
elimination  of  backtracking  and  Its 
replacement  by  a  single  FOR  loop  that 
iterates  through  a  set  of  instantiations 
of  the  compound  pattern.  It  also  rakes  it 
possible  to  apply  intelligence,  within  the 
pattern  matcher,  to  determine  how  best  to 
obtain  valid  instantiations. 

Additionally.  Model  Completion 

utilizes  only  a  subset  of  AP/1  (which  is 
also  the  implementation  language  for  the 
project)  to  further  simplify  the  writing 
and  analysis  of  Precise  Model  programs. 
The  major  difference  is  that  the  Precise 
Mcdel  utilizes  no  free  or  local  variables, 
except  for  pattern-match  variables,  that 
are  instantiated  during  the  matching 
process.  All  communication  between 
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routines  is  either  by  way  of  explicit 
parameter  passing  or  through  data 
contained  in  the  Domain  Model. 

AP/1  generally  allows  the  arbitrary 

mixinq  of  tuoles  to  be  instantiated  and 

functions  to  be  evaluated.  This  includes 

tnt  fv.r.ctJcr.3  AND,  OR,  and  NOT,  as  veil  as 

any  other  defined  LISP  functions.  It  is 

assumed  that  such  functions  have  no  side 

effects.  Each  tuple  in  an  expression  is 

treated  as  a  ^unction  and  evaluated  if  it 

has  a  function  definition.  If  not,  then 

it  is  treated  as  a  pattern  to  be 

instantiated.  Because  there  are  no  free 

variables  and  the  only  local  variables  are 

pa*,  tern-natch  variables,  the  rule  for 

instantiation  is  very  simple.  Any 

# 

parameter  or  variable  unbound  at  the  time 
it  is  encountered  within  a  pattern  is 
i nstanti ated;  already  bound  variables  are 
left  unchanced. 

The  value  of  a  pattern  is  always  the 
instantiated  version  of  that  pattern  if 
the  maten  was  successful,  or  ML 

otherwise.  Because  no  other  possibilities 
exist,  all  pattern  matches  return  either 
the  Instantiated  pattern  or  NIL.  The 

concept  of  fai lure  does  not  exist  within 
the  pattern  matcher,  since  it  always 
returns  to  its  caller  with  one  or  the 


other  of  these  values. 

The  routines  (statement'' )  that  invoke 
the  pattern  matcher  may  take  other  actions 
upon  the  returned  value.  They  nay 
extract  from  it  particular  bi  idings  or 
subexpress i ons  or  cause  failure  when  a 
IIL  value  is  sturned  E  ^h  of  the 
"statements"  in  AP/1  is,  in  fact,  a 
function  that  uses  the  value  returned  from 
the  pattern  matcher  as  it  sees  fit.  In 
this  repaid,  the  AND,  uR ,  and  NOT 
functions  are  no  ci  fferent  than  any  other 
in  the  system. 

Current  Project  Status 

AP/1  and  the  associative  data  base 
mechanisrs  it  relies  on  have  been 
implemented,  and  it  has  been  used  i  r.  turn 
to  implement  an  initial  version  of  the 
Model  Completion  phase.  This  version  is 
able  to  take  (carefully  selected)  small, 
simple  domain  and  problem  statements  in 
Loose  Model  form  and  convert  them  to 
running  programs  py  performing  a  series 
of  structuring  and  program  building 
transformations  that  reorder  the  arguments 
of  relations  and  actions,  convert  the 
urruments  to  the  correct  type,  and  fill  in 
missing  ones.  Ihey  also  fill  in  omitted 
relations  between  objects,  convert 
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PROGRAMMER'S  INTERFACE 


actions.  Implications,  and  constraints  to 
procedural  form,  and  infer  Implied 
relations  needed  to  make  sense  of 
structures  in  the  Loose  Model. 

In  all  cases,  these  transformations 
are  not  complete.  They  recognize  only 
specific  simple  instances  of  the  desired 
situation.  During  the  next  year,  we  plan 
to  extend  the  range  of  these 
transformations,  include  new  ones,  and 
implement  ar  initial  version  of  Domain 
Acquisition  to  form  a  complete  system. 

One  problem  In  particular  will  be 
attacked.  Currently  the  system  attempts 
to  make  each  part  of  the  generated  program 
"precise*’  (that  is,  well-defined),  and 
stops  transforming  each  part  when  this 
goal  is  satisfied.  However,  In  the 
Generated  progra..  ,  only  certain  "precise" 
forms  will  occur  in  the  data  base,  and  all 
those  used  must  work  In  harmony  with  each 
other.  Thus  only  certain  "precise4*  forms 
should  be  acceptable?  this  set  must  be 
determined  on  a  global  basis. 

THE  PROGRAMMER'S  INTERFACE 

The  Programmer's  Interface  (PI) 
addresses  the  general  problem  of  creating 
a  suitable  on- I i no  environment  for 
programming.  The  amount  of  software  to 


support  such  an  on-line  envi renment,  and 
the  effort  required  to  produce  it,  is  very 
large  relative  to  that  needed  to  produce  a 
programml no  language,  a  fact  that  largely 
accounts  for  the  scarcity  of  such 
programming  environments.  This  factor  was 
largely  responsible  for  the  discarding  of 
a  major  language  (QA**  [6])  as  a  separate 
entity  and  Its  inclusion  instead  as  a  set 
of  extensions  in  a  LISP  (S3  environment. 
The  few  systems  that  do  exist  (e.g.,  LISP, 
APL,  EASIC,  and  PL/I)  have  greatly 
benefited  their  users  and  have  strongly 
contributed  to  the  widespread  acceptance 
<f  »-he  associated  language. 

At  a  bare  minimum,  a  suitable 
programming  environment  consists  of 
an  on-line  interpreter  (or  incremental 
compiler),  an  integrated  interactive 
source- I  eve  I  debugging  and  editing  system. 


and  a  supporting  file 

structure.  More 

extensi ve 

envi ronments 

wou  1  d 

i ncl ude 

such  faci  1 

1 ti es  as  automatic 

spel 1 i ng 

correction. 

structural 

edl tors. 

trad  ng 

packages. 

test  case 

generators,  docu- 

mentation  facilities,  and  so  forth. 

Examining  several  programming  envi¬ 
ronment  systems,  one  recognizes  a 
great  deal  of  uniformity.  Most  of  the 
software  supporting  these  systems  Is 
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similar  in  both  its  organizational 
structure  and  functions.  In  fact,  the 
systems  differ  in  detail  more  because  of 
differences  in  style  among  system 
designers  than  because  of  differences 
required  by  the  programming  languages. 

The  PI  concept  attempts  to  exploit 
this  uniformity  by  creating  a  single 
programming  environment  capable  of  easily 
interfacing  users  with  a  vide  variety  of 
on-line  programming  languages.  The  Pi  is 
thus  responsible  for  transforming  these 
programming  1 anguages  Into  systems.  The 
cost  of  providing  such  an  environment  for 
a  lanquage  would  drop  from  the  several 
man-years  now  required  to  the  few  man-days 
(estimated)  to  interface  to  a  PI. 
Additionally,  the  existence  of  a  common 
prooramminq  environment  for  many  different 
languages  would  justify  including  further 
capabi li t i es. 

This  common  programming  environment 
provided  by  a  PI  should  Include  facilities 
for  creating,  modifying,  storing,  and 
retrieving  programs;  on-line  debugging. 
Including  trace  and  break  facilities  as 
well  as  the  facilities  of  the  language  for 
evaluation  of  expressions  at  breaks; 
modifying  the  interface  between  routines 
'via  an  AOVISE  [7]  capability);  automatic 


spellinq  correction;  remembering,  mod¬ 
ifying,  and  reissuing  previous  inputs; 
and  undo! no  the  effects  of  any  of  these  PI 
faci 1 i ti es. 

Sucn  a  PI  has  been  constructed  and 
interfaced  to  the  programming  lanquage 
ECL  [8].  The  remainder  of  the  PI 
discussion  exp’ains  the  PI  concept  in 
terms  of  this  implemented  program. 
The  deficiencies  of  this  particular 
implementation  are  discussed  in  the 
Evaluation  subsection. 

System  Archl tecture 

The  facilities  provided  by  the 
i  r.|>  1  emented  Programmer's  Interface  (PI-1) 
are  based  on  the  INTERLISP  (form  riy 
BBN-L1SP)  system.  In  fact,  they  are 
the  facilities  of  this  system,  as 
mod i f i ed  for  language  independence.  P I  —  1 
itself,  implemented  in  INTERLISP,  coexists 
with  the  facilities  it  invokes  to  provide 
the  programming  environment.  INTERLISP 
was  chosen  as  the  basis  both  because  it 
already  had  an  extensive  set  of 
programming  tools  In  an  accessible  form 
and  because  the  structure  and  operation  of 
the  tools  could  easily  be  altered  to 
operate  as  required  for  a  PI. 
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The  system  structure  Is  shown  In 
Figure  1.1.  The  ARPANET  [9]  Is  used  as  the 
communications  mechanism  between  PI-1  and 
the  user's  language  processor,  a  choice 
which  has  three  advantages.  First,  it 
allows  PI-1  to  be  Interfaced  to  any 
language  processor  available  on  the 


Figure  1.1  System  architecture 


ARPANET,  independent  of  what  machine  It 
runs  on.  Second,  this  interfacing  can  be 
done  by  PI-1  without  the  knowledge  of  the 
language  processor?  thus  no  modifications 
to  the  language  processor  are  required. 
Finally,  the  use  of  the  ARPANET  greatly 
simplifies  implementing  the  i ntercon- 
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for 

communi cat!  on 
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than 
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Three  properties  are  required  of  a 
language  processor  to  be  used  with  a  PN 


1)  A  way  must  exist  to  form  a  coroutine 
linkage  between  the  language 
processor  and  the  PI  by 

interconnecting  their  I/O  ports. 
This  cype  of  linkage  is  discussed  in 
detail  in  Ref.  10.  With  PI-1,  the 
ARPANET  provides  this  linkage.  Thus, 
for  PI-1,  any  language  processor 
available  on  the  ARPANET  satisfies 
the  first  requirement. 


2)  It  must  have  an  on-line  evaluator 
(either  an  interpreter  or  fast 
compiler)  and  be  able  to  field  breaks 
or  errors  within  a  computation. 


3)  It  must  be  able  to  evaluate  arbi trary 
forms  in  that  language  either  at 
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breakpoints  or  at  the  top  level. 

PI- I  begins  processing  user  Input  by 
storing  It  In  a  history  list  used  by  the 
Programmer 's  Assistant  [73  (an  INTERLISP 
subsystem)  to  retrieve,  edit,  group, 
reissue,  or  undo  previous  commands.  PI-1 
then  ‘»xainines  the  Input  to  determine 
whether  It  should  be  processed  by  an 
INTERLJ  SP  facility  or  by  the  user's 
language  processor.  Basically,  envi¬ 
ronment-type  activities,  such  as  loading 
files,  editing  programs,  advising  a 
function,  etc.,  are  performed  within 
PI-1,  while  expressions  in  the  user's 
language  to  be  evaluated  are  passed  to  the 
language  processor. 

If  the  user's  input  is  intended  for 
his  language  processor,  it  is  passed 
across  the  ARPANET  to  that  language 
processor.  Any  output  generated  by  the 
processor  is  received  across  the  ARPANET, 
again  by  PI-1.  It  suppresses  the  echo  of 
the  input  and  passes  the  cutout  to  the 
user,  extracting  from  it  the  "value*1  and 
putting  it  into  the  history  list  for  use 
by  the  Programmer 's  Assistant. 

If  the  user's  input  is  an 
envi ronment-type  command  and  should  be 
performed  within  PI- I,  the  appropriate 
facility  is  Invoked.  In  simple  cases  the 


operation  completes,  returns  a  value  that 
is  put  in  the  history,  and  another  input 
Is  processed.  In  more  complex  situations, 
some  interaction  is  equi red  during  the 
operation  with  the  user's  language 
processor;  this  is  accomplished  by 
dynamically  generating  a  series  of  inputs 
for  the  language  processor  that  will  have 
the  desired  effect  or  return  the  desired 
information.  These  are  passed  through  the 


communicati ons 

rrechani  sms 

to 

the 

processor;  its 

output  is 

captured. 

and 

either  the  success  of  the  modifications  Is 
verified  or  the  desired  information  Is 
extracted.  Any  number  of  such  cycles  may 
be  regui red  before  the  PI-1  facility 
completes  its  processing  of  the  user's 
command.  As  an  example,  consider  the 
loading  of  a  file.  As  the  function 
definitions  are  read  in,  they  are  stored 
as  a  property  of  the  correspond! no  atoms 
to  be  used  by  the  PI-l's  editor  for  any 
modi f icati ons  required  later.  The 

function  definitions  are  also  passed  to 
the  language  processor  so  that  i  t  can  use 
these  for  valuation.  Thus,  one  cycle  is 
required  foi  eacn  function  defined  in  the 
f  i  ie. 

PI-1  maintains  a  copy  of  all 
functions  defined  by  the  user,  and  this  is 
used  by  PI-l's  editor  when  the  user  alters 


13 


"  ■"■"W  W— f.fl 


programmer's  inter*  ace 


the  definition.  Whenever  this  definition 
changes  (by  redefinition  or  through 
exitinq  the  editor),  the  resulting 
definition  Is  passed  to  the  language 
processor  as  a  new  definition  of  the 
f unct I  on. 

Inter facl ng  a  Language  to  a  Programmer 's 
Interface 

Most  of  PI-1  Is  language- i  ndep*  ..cent , 
but  the  following  portions  must  be 
modified  to  accept  a  new  language:  syntax 
modification,  synchronization,  program 
writing,  and  debugging. 

The  INTERLISP  edftcr  used  by  PI-1  is 
structural  rather  than  str i nn-or I ented. 
To  be  effective,  the  text  It  is 
manipulating  must  have  a  structural  basis. 
The  syntax  modification  routines  are 
responsible  for  introducing  the  structure 
Into  the  user's  languaae  (only  for  use 
within  PI-1).  This  structure  is  of  two 
forms.  First  is  the  grouping  of 
characters  Into  lexical  units.  The  user's 
language  may  have  very  different  lexical 
grouping  rules  than  LISP,  and  the  syntax 
modification  package  is  responsible  for 
the  lexical  analysis.  Second,  the  lexical 
units  thus  produced  are  grouped  Into 
larger  units  by  the  use  of  parentheses. 


These  units  can  be  nested  within  one 
another  to  form  the  familiar  LISP 
S-expresslon  structure.  The  designer  of 
the  syntax  modifier  must  decide  where  to 
introduce  tnls  structual  grouping.  In 
ALGOL- l Ike  languages.  It  would  be  natural 
to  qroup  the  lexical  units  of  a  statement 
together  and  groups  of  statements  within 
blocks  together.  The  structural  groupings 
selected  are  introduced  into  all  program 
text  input  by  the  user  and  employed  by  him 
to  direct  the  editor  in  its  modifications 
of  this  text.  When  this  text  is  passed  to 
the  language  processor,  those  structural 
groupings  artificially  Introduced  ter 
editing  purposes  are  removed  before 
transmi ssi on. 

PI-1  and  the  language  processor  must 
be  kept  in  synchronization  with  each 
other.  Logically  this  is  very  simple;  It 
Is  accomplished  by  having  PI-1  wait  until 
the  language  processor  has  completed 
evaluating  the  previous  input  before 
giving  it  another.  This  situation  is 
signaled  by  the  language  processor's 
attempt  to  read  the  next  input. 
Unfortunately  (due  to  a  deficiency  In  the 
network  protocol),  this  information  Is  not 
aval lable.  Therefore  the  language 

processor's  state  of  readiness  must  be 
determined  by  examination  of  its  output 
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stream.  Fortunately,  most  on-line 
lanouage  processors  explicitly  inolcate 
their  readiness  for  more  input  by 
providing  the  user  with  a  Prompt 
character.  The  language  processor's 
output  must  be  scanned  for  this  character, 
and  this  action  is  used  as  a 
synchronization  mechanism  between  PI- l  and 
the  language  processor. 

Several  facilities  within  PI-1,  such 
as  Break,  Trace,  and  Advise,  cause 
additional  statements  to  be  written  Into 
the  user's  program  for  evaluation  at 
runtime.  The  interfacer  of  a  new  language 
must  specify  the  form  of  these  additions. 

PI-1  contains  many  advanced  debugoing 
capabilities  not  found  In  most  language 
processors.  All  of  these  aids  are  based 
on  information  gathered  during  execution 
or  at  a  breakpoint  within  the  program.  To 
use  these  facilities,  the  designer  of  the 
language  interface  must  supply  routines 
that  provide  the  basic  information  on 
which  these  debugging  aids  arc  built. 

PI-1  was  implemented  and  debugged  in 
approximately  three  weeks.  Including  the 
language  interface  to  ECL.  Although  no 
other  language  interfaces  have  yet  been 
built.  It  is  estimated  that  an  Interface 
to  another  suitable  language  could  be 


designed,  implemented,  and  debugged  in 
less  than  a  week. 

bva 1 uation 

The  significance  of  th£  PI  effort 
lies  neither  In  the  particular  interface 
provided  between  IMTERLlSP  and  ECL  nor  in 
the  extensive  capabilities  provided  the 
user,  but  rather  in  1)  the  observation 
that  very  little  cf  the  interface  itself, 
or  of  the  capabilities  provided.  Is 
language-dependent;  2)  the  recognition 
that  the  pr  ogramml ng  envi ronment  can  be 
effectively  split  into  an  "environment" 
part  anc  an  execution  and  evaluation  part; 
and  3)  the  experience  qained  from  building 
such  a  system  and  interfacing  a  language 
to  it. 

PI-1,  however,  suffers  from  a  number 
of  def I ci enci es,  the  most  Import  t  of 
which  Is  the  use  of  already  existing  tools 
in  environments  more  general  than  those 
for  which  they  were  designed.  This  was 
most  notable  in  the  use  of  LISP's  editor 
for  nor.structured  text  (making  it 

necessary  to  introduce  structure  by 
parentheses)  and  the  requirement  to 


replace  LISP 

's  1  nput 

routi nes 

to  provi de 

the  proper 

lexi ca 1 

anal ysi s 

for 

the 

i nter  faced 

1  anguage. 

Both 

of 

these 
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problems  could  be  avoided  In  a  PI  If  It 
used  the  syntax  description  of  the 

language  to  guide  the  input  and  the 
editing  and  display  of  programs. 

While  one  of  the  strengths  of  the  PI 
concept  is  the  split  between  "environment" 
and  evaluation,  this  split  introduces 
the  problem  of  communi  cac i on  and 

synchronization,  for  each  part  must  keep 
the  other  informed  about  changes  it  makes 
that  affect  the  other.  In  PI-1,  this 
communication  and  synchronization  was 

partial  and  clumsy.  The  flow  of 
Information  from  the  environment  to  the 
evaluation  part  was  adequate,  but  the 
reverse  flow  was  not.  The  need  to 
communicate  to  another  program  suitable 
explanations  of  the  state  of  the 
evaluation,  the  cause  of  the  error,  or 
even  that  an  error  occurred,  was  simply 
not  envisioned  or  planned  for. 

PI-1  has  thus  demonstrated  that  a 
moderately  integrated  PI  can  be  built 
whose  facilities  are  far  beyond  what  is 
typically  available  at  a  fraction  of  the 
cost.  However,  development  of  a  highly 
integrated  PI  .will  have  to  await  a 
better  understanding  of  the  functional 
requirements  of  a  language  processor  In 
such  an  environment. 


Although  the  PI  has  been  interfaced 
to  only  one  language  (ECL),  and  altltough 
It  contains  only  a  small  fraction  of  the 
capabilities  ultimately  desired,  it  is 


having  a 

major 

effect  by 

acting  as  a 

prototype 

for 

the 

NSW  described  below 

111.123, 

whi  ch 

is 

bei  ng 

undertaken  to 

develop  this  understanding  and  provide  a 
single,  common,  comprehensive  programming 
environment  interfaced  to  a  wide  variety 
of  languages  running  on  many  different 
machines  communicating  through  a  network. 
New  languages  or  machines  could  be 
interfaced  to  the  system  at  a  fraction  of 
the  cost  of  providing  a  separate 
programminc  environment.  Widespread  usage 
would  Justify  the  expenditure  of  more 
resources  to  auoment  and  improve  th: 
capabilities  provided.  Such  a  PI  could 
free  users  from  having  to  develop  their 
programs  using  only  software  available  on 
their  own  machines  and  could  provide  a 
much  more  comprehensive  and  coordinated 
software  development  package  than  is 
currently  available. 

THE  NATIONAL  SOFTWARE  WORKS 

The  production  and  maintenance  of 
large  proqrams  is  still  an  outrageously 
expensive  activity;  the  costs  are  not  only 
high,  but  also  difficult  to  predict  or 
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control*  Aside  from  the  manifest  benefits 
derived  from  the  use  of  compilers  and 
(some)  operating  systems  and  a  certain 
amount  of  improvement  experienced  by 
programmers  who  coue  Interactively,  it  is 
not  at  all  clear  that  the  last  twenty 
years  of  research  and  development  In 
programming  technolog',  have  made  any 
serious  inroads  upon  the  problem.  This 
situation  is  particularly  interesting  in 
the  light  of  a  general  suspicion  that,  in 
principle,  the  problem  ought  to  be  eased 
by  the  creation  of  better  software  to 
support  the  proqram  production  and 
maintenance  process,  for  surely  a  great 
deal  has  been  spent  in  the  effort  to 
Invent  Just  such  software.  The  reasons 
for  our  failure  are  arguable;  a  variety  of 
hypotheses  have  been  put  forwards 

■  That  the  necessary  tools--or,  at  least, 

many  of  them — exist  in  the  research 
centers  but  are  not  being  effect¬ 
ively  delivered  to  the  practical 
programml ng  communi ty. 

■  That  feedback  from  the  user  community 

has  insufficient  Influence  on  the 
research  laboratories,  so  that 
research  emphasis  Is  unrelated  to 
user  needs. 


■  That  the  necessary  tools  exist,  but  are 


d! ffused 

over 

a  variety  of  hardware 

l  n 

many 

physical  locations,  the 

problem 

be  I  ng 

that  of  difficulty  of 

access. 

Each 

of 

these 

hypotheses — and  the 

list  may  readily  be  extended — doubtless 
contains  a  certain  amount  of  truth,  and 
collectively  they  surely  suggest  that 
dramatic  improvements  in  the  way  programs 
are  built  are  less  likely  to  come  from 
marginal  improvements  in  present  tools  (or 
the  Invention  of  some  magical  new  one) 
than  from  better  methods  cf  tool  access 
and  delivery  and  better  communi cat i on 
between  research  laboratory  and  end  user. 

The  idea  of  a  National  Software  Works 
(NSW)  on  the  ARPANET  [lJ]  arose  fairly 
naturally  from  these  considerations.  If 
some  number  of  end  users  were  put  on 
the  network,  and  enouqh  additional 
off-the-shelf  software  were  brouqht  up  on 
the  network  to  supply  a  complete 
set  of  conventional  tool  s--coi...  i  ers, 
documentat i on  aids,  debugging  systems, 
etc.  —  for  normal  program  development  work, 
some  useful  results  might  be  expected  to 
fol low: 

■  The  user  would  immediately  have  more 

convenient  access  to  standard  tools 
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unavailable  on  his  own  hardware  (or 
seldom  available  if  his  hardware  Is 
often  tied  up  running  production). 

■  The  user  would  find  it  easy  to  access 
novel  tools  in  use  at  research 
facilities  presently  on  the  network, 
but  not  otherwise  available  to  him. 

*  Contact  between  the  research  labor¬ 
atories  and  the  user  community  would 
naturally  improve. 

In  sum,  the  NSW  might  both 
immediately  Improve  the  present  situation 
of  the  user  and,  in  the  long  term,  provide 
an  effective  vehicle  for  the  communication 
of  need  from  user  to  researcher  and  of 
responsive  tool  from  researcher  to  user. 

It  was  soon  recognized,  however,  that 
a  view  of  the  NSW  as  a  mere  lash-up  of 
tools  that  happened  to  reside  on  the 
ARPANET  would  be  extremely  short-sighted. 
The  fact  that  all  programmer  contact  with 
tools  would  pass  through  a  common 
communication  mechanism  with  Immense 
computing  resources  created  a  golden 
opportunity  for  the  study — and  perhaps 
control — of  the  whole  process  of  creating 
and  maintaining  large  programs.  This 
thought,  was  particularly  attractive  In  the 
light  of  our  feeling  that  one  of  the  most 


weakly  supported  areas  in  the  production 
and  maintenance  process  Is  project 
management--a  tool  that  keeps  track  of 
what  Is  going  on.  relating  particular 
programmer  activities  to  each  other  and  to 
the  overall  project. 

The  NSW  Envi ronment 

Against  the  background  of  our  feeling 
that  serious  progress  in  making  the 
production  of  large  programs  a  more 
rational  process  will  come  less  from  the 
polishing  of  particular  tools  than  from  a 
frontal  attack  on  the  issue  of  Improved 
access  to  tools  and  centralized  management 
of  the  vast  Inventory  of  text  floating 
around  a  larqe  project,  the  logic  of  our 
NSW  strategy  becomes  easy  to  see. 

■  It  Is  our  Intent  to  put  a  project's 

programmers  on-line  to  the  ARPANET, 
which  has  the  Immediate  effect  of 
giving  them  access  to  many  tools 
unavai lable  on  their  own  local 
hardware. 

■  We  will  supply  Interactive  editing 

packages,  both  a  general  text  editor 
and  editors  that  •speak"  one  or  two 
common  programming  languages.  The 
effect  of  such  tools  In  facilitating 
program  preparation  and  modification 
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is  too  well  known  to  require  any 
defense  here, 

■  Projects  will  be  able  to  store  these 

files  on  very  Inexpensive  on-line 
mass  storage  devices  (such  as  the 
Datacomputer  [14]).  This  should 
relieve  a  considerable  part  of 
a  project's  local  off-line  file 
maintenance  problems  and  facilitate 
load-sharing  when  the  project's  local 
computer  Is  busy. 

■  A  File  Manager  will  always  be  on-line 

monitoring  the  content  and  structure 
of  the  project's  files  and  keeping 
the  books  up  to  date,  as  text  pieces 
are  created  and  manipulated. 

The  presence  of  the  first  three 
facilities  will  permit  the  project  to 
conduct  its  business  more  or  less  as  it 
does  new  (using  the  same  languages, 
the  same  tools,  etc.)  with  certain 
improvements  ?n  ease  of  tool  access  and 
foreign  hardware  access,  editing,  and  file 
management.  In  addition,  the  project  may 
at  Its  option  experiment  with  using 
different  tools  scattered  around  the 
network. 

The  fourth  facility  opens  the  door  to 
some  genuinely  new  ways  of  controlling 


projects  in  the  future.  To  begin  with,  a 
fairly  powerful  query  system  will  be 
provided  to  answer  questions  about  any 
filed  entity:  what  It  Is,  where  it  came 
from,  what  other  entities  depend  on  It, 
etc.  Later  we  will  Introduce  a  variety  of 
experimental  tools  for  project  control 
that  use  the  File  /Manager's  books  as  their 
primary  data  or  that  use  the  fact  of  the 
File  Manager's  existence  as  their  means  of 
ir vocation  (after  all,  the  latter  provides 
a  sinqie  control  point  "awakened"  every 
time  anything  interesting  happers). 

Support! ng  Technoi oqy 

Virtually  all  multi  program  operating 
systems  have  attempted  to  create  a 
suitable  programming  environment  by 
providing  a  set  of  tools.  Some  merely 
provided  a  library  from  which  tools  could 
be  selected  one  at  a  time  by  the 
programmer.  Others,  like  MULT  ICS,  CP-67, 
VS,  and  TENEX,  have  provided  an  on-line 
environment  for  program  building  and 
debuggi ng. 

All  of  these  systems  nave  been  built 
on  a  single  computer,  which  has  severely 
limited  their  capability  to  provide  the 
type  of  environment  described  In  the 
previous  subsection.  In  fact,  until 
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recently  a  combination  of  several  such 
hardware  and  software  technical  problems 
existed  that  prevented  the  conception 
and  Implementation  of  this  type  of 
environment.  These  problems  and  their 
solution  In  the  NSW  are  discussed  below. 

Si  ngle-machl  ne  l  mpl e.iientat  1  on  of  a  1  1 
tools.  Computer  networks,  such  as  the 
ARPANET,  have  established  a  communication 
mechanism  whereby  cooperating  programs  In 
different  machines  can  funr^on  together 
as  a  single  system.  The  technical  basis 
for  eliminating  these  problems  Is 
provided  by  computer  networks,  centralized 
mass  storage,  the  PI  [1A]  described  In  the 
previous  section,  ACTORS  [15],  and 
execution  machines  (see  the  System 
Description  subsection  below).  The  PI  has 
utilized  this  network  technology  to  create 
an  on-line  programming  environment 
combining  tools  that  run  on  different 
machi nes. 

Noni  ntegrated "tool -at-a- t 1  me" systems. 
Current  systems  either  segregate  their 
tools  Into  noninteracting  components 
Invoked  one  at  a  time  or  provide  highly 
complex  Integrated  versions  of  these,  with 


the 

Interactions  between 

them 

built 

l  nto 

the 

systems  themselves. 

The 

type 

of 

programming  environment  we  envision 
requires  that  actions  or  events  In  one 
part  of  the  system  permeate  the  rest  to 
maintain  consistency  and  coordination 
between  the  components.  The  ACTORS 
concept,  by  externalizing  and  removing  the 
control  and  communication  between  the 
component  parts,  greatly  simplifies  the 
construction  of  an  Integrated  and 
coordinated  syr  em. 

Machi ne  i ndependence.  Although  tools 
running  on  different  machines  may  be 
Integrated  Into  a  single  tool,  the 
technology  does  not  exist  to  run  a  single 
program  on  several  different  machines  and 
obtain  the  same  results.  Therefore, 
software  being  produced  must  be  executed 
and  tested  on  the  machine  for  which  it  Is 
Intended  to  run  In  production  mode.  Thus, 
If  the  software  environment  Is  to  be  used 
to  produce  programs  for  more  than  one 
machine,  each  of  these  must  be  connected 
through  the  computer  network  and  a  small 
portion  of  the  system  replicated  on  each 
execution  machine  to  provide  for 
translation  and  run-time  monitoring 
capabilities.  The  rest  of  the  software 
environment  Is  common  and  can  be  shared 
Independent  of  the  machine  for  which 
execution  Is  Intended. 


» 


i 
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Language  Independence.  Currently,  If 
software  is  to  be  produced  for  more  than 
ore  lanquage,  then  the  tools  must  either 
be  duplicated  in  separate  and  distinct 
integrated  programming  environments  or 
else  available  in  a  non! ntegrated 
tool-at-a-ti  me  mode.  The  PI  has  shown 
that  mat./  of  these  tools  are 
1 anguage- I ndependent  or  only  slightly 
language-dependent  and  has  demonstrated 
how  such  tools  can  be  extended  to  handle  a 
wide  set  of  programming  languages.  It 
utilizes  the  programming  tools  (editors, 
file  systems,  debuggers.  Programmer's 
Assistant  [73,  etc.)  developed  for  rne 
language  (LISP  [5])  for  the  development 
of  software  in  other  languages  (e.g.P  ECL 
C  8  j )  •  It  has  established  Interface 

requirements  for  other  languages  that 
would  greatly  reduce  the  effort  required 
to  transform  these  from  simple  interactive 
programming  languages  into  an  extensive 
programming  environment. 

Economi cs .  In  addition  to  the  costs 
of  creating  an  appropriate  programming 
environment  addressed  above,  several 
economic  factors  currently  limit  the 
•jse  and  utility  of  existing  programming 
environments.  Most  machines  are  sized 
for  their  production,  not  development, 
requirements.  Hence,  typically  they 


contain  neither  enough  mass  storage  for 
the  files  that  would  be  required  in  an 
on-line  environment  nor  enough  memory  to 
support  both  the  code  being  developed  and 
the  tools  for  that  development.  Also, 
access  to  the  system  is  limited  by  the 
priori t>es  of  the  production  workload. 
Networking  and  economies  of  scale  offer 
solutions  by  providing  access  to  a  system 
specifically  designed  and  sized  for 
software  development  and  on  which  no 
production  workload  exists.  Charges  would 
be  based  on  usage  and  development  costs 
for  the  system,  spread  over  a  much  wider 
communi ty  of  users  because  of  the 
language-  and  machi ne- I ndependence  aspects 
of  the  system.  in  addition,  very  cost- 
effective  mass  storaqe  can  be  provided  by 
the  Oatacomputer ,  which  provides  a 
trillion-bit  on-line  memory  at  a  cost  of 
about  a  dollar  per  megabit  per  year. 

System  Descr i pti on 

The  hardware  for  the  NSW,  snown  in 
Figure  1.2,  consists  of  three  logical 
components  interconnected  by  the  ARPANET • 
mass  storage,  the  execution  machine,  and 
the  interactive  machine.  The  first 
consists  of  the  Oatacomputer,  composed  of 
a  trillion-bit  store  and  a  file  management 
system.  The  second,  the  execution  machine, 
is  a  set  of  machines  responsible  for 
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running  the  program  being  developed 
and  for  collecting  dt  a  on  its  execution. 
For  each  proqram  beinq  developed,  the 
execution  machine  chosen  is  automatically 
the  same  as  the  production  machine  for 
that  program.  Tnus,  during  development,  a 
program  is  executed  on  the  same  (actually 
a  copy  of  the)  machine  it  will  run 
on  during  production.  This  mechanism 
eliminates  all  mar.hi  ne-dependence  compat- 


Figur*  1.2  NSW  hardwore 


ibility  Issues  at  the  cost  of  replicating 
the  execution  software  In  each  machine  for 
which  this  capability  Is  desired  and 
having  that  machine  available  in  the  NSW. 
On  the  other  hand,  it  provides  the  great 
advantage  cf  allowing  the  final  component, 
the  interactive  machine  (or  machines),  to 
be  independent  of  the  choice  of  production 
machine,  thereby  allowing  It  to  handle  a 
wider  set  o.'  Implementation  efforts.  The 
interactive  macine  contains  most  of  the 
system's  software  and  provides  ail  of  the 
facilities  of  the  NSW  except  those 
described  above. 

The  ARPANET  not  only  interconnects 
the  NSW  components,  but  also  provides 
access  for  users  to  the  system  and 
supports  a  variety  of  terminals.  However, 
the  NSW  will  be  oriented  toward  the  use  of 
high-capacity  video  terminals. 

Although  the  system  is  distributed 
across  the  ARPANET,  it  Is  organized  so 
that  neither  the  user  nor  the  component 
software  modules  are  aware  of  this.  The 
user  sees  c  ’y  a  single  integrated 
facility.  The  framework  enables  modules 
either  locally  or  remotely  connected  to 
communicate  without  knowing  each  other's 
precise  location. 
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System  Growth 


Tnough  we  have  described  the  NSW 
sysvem  and  its  tool  Interface  at  length, 
we  have  not  discussed  the  tools 
themselves,  partly  because  we  believe  It 
Is  the  delivery  and  access  system  rather 
than  specific  tools  which  Is  significant, 
partly  because  many  of  the  tools  to  be 
Included  already  exist,  and  mainly  because 
NSW  does  not  plan  cn  Deco. mi ng  involved  in 
a  massive  tool  development  effort. 
Rather,  NSW  has  been  designed  to  create  a 
competitive  marketplace  m  which  vendors 
make  tools  available  on  a  usage  charge 
basis.  Such  a  marketplace  has  advantages 
for  all  concerned.  Because  the  NSW  vi  I! 
eventually  have  a  verv  »arge  user  base, 
vendors  will  have  a  wider  audience  from 
which  to  recover  their  development  costs. 
Hore  i  m  ;  >rt  ant  1  y,  ,lnce  the  entire  user 
population  can  access  and  use  the  tools 
independent  of  their  own  production 
hardware  (unless  the  tool  is  dependent  on 
the  execution  machine),  a  single 
f  mplementat.'on  Is  sufficient.  The 


Implemcnter  Is  free  to  choose  the  most 
cost-effective  r.achlne  for  development  and 
execution  of  his  tool.  Users  are  able  to 
choose  the  best  tool  available  and  are  not 
restricted  to  software  running  on  their 
own  hardware.  Finally,  because  NSW  does 
all  the  accounting  for  all  users,  t 
decision  of  which  tools  to  Install  in  t,  e 
NSW  and  which  ones  to  use  can  be 
distributed.  Vendors  who  oelieve  in  the 
economic  viability  of  their  tools  can 
Install  them  and  make  the  use,*  aware  of 
their  aval labi 1 1 ty .  Users  can,  on  an 
individual  basis,  decide  which  tool  Is 
mo^t  appropriate  for  their  own  needs  and 
can  try  new  tools  witnout  any 
admi ni strat i ve  arr angements . 

ISI,  together  with  other  members  of 
the  ARPA  community,  was  Instrumental  In 
the  conception  and  design  of  the  National 
Software  Works.  During  the  remainder  of 
the  project,  we  will  provide  technical 
coordination  and  planning  for  Its 
development  and  growth. 
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"The  concepts  of  program  verification  are  actually  the  cornerstone  of  any 
deeper  understand! ng  of  algorithms,  without  which  the  programmer  would  have  no 
other  tool  besides  his  own  Insufficient  Intuition." 


INTRODUCTION 

To  verify  a  computer  program  means  to 
demonstrate,  by  a  mathematical  proof,  the 
consistency  between  the  program  and  the 
specifications  or  documentation  of  what 
the  program  Is  to  do.  Program 
verification  can  have  a  great  Impact  on 
the  construction  of  reliable  software  by 
assuring  that  programs  actually  do  what  Is 
Intended  and  by  ultimately  reducing 
software  costs.  In  addition,  program 
verification  helps  to  Influence  the  design 
of  programming  languages.  It  also  serves 
as  an  Important  test-bed  for  advances  In 


NIklaus  Mirth,  Systematic  Programming: 

An  Introduction.  1973.  p.  xTT? 

both  programming  methodology  and  the 
semantic  definition  of  programming 
languages. 

Program  verification  Is  not 
Inexpensive  or  rapidly  completed,  but  It 
need  not  be  an  additional  cost  In  software 
projects.  In  Boehm's  data  on  current 
software  practices  [13,  It  Is  especially 
relevant  to  note  the  large  amounts  of  time 
and  effort  (45  to  50  percent)  devoted  to 
testing  activities,  much  of  which  can  be 
eliminated  by  verification  procedures. 

It  Is  now  technically  possible  to 
verify  small  programs  automatically. 
Techniques  and  experience  exist  to  permit 
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the  computer-assisted  verification  of  more 
ambitious  programs.  If  necessary.  It  is 
even  possible  to  verify  stl  1  i  more 
ambl 1 1 ous  programs  manua 1 1 y. 

A  PROGRAM  CONSTRUCTION  AND  VERIFICATION 
SYSTEM 

The  Program  Verification  project  Is 
building  an  Integrated  system  of  software 
tools  to  aid  In  the  design  and 
construction  of  verified  programs  <<nd  to 
experiment  with  new  specification 
languages,  structuring  methods,  and  proof 
methods.  V.'e  fully  expect  to  demonstrate 
the  system's  feasibility  and  practical 
applicability  on  significant,  real 
progr  >^s. 

Previous  experience  with  actual 
proofs  of  a  variety  of  programs  and  with 
various  experimental  program  verification 
systems  supports  two  conclusions:  (1) 
automatic  or  Interactive  program  verifiers 
can  be  of  significant  help  In  proving 
actual  programs,  and  (2)  the  best  way  of 
exploiting  existing  program  proving 
methods  Is  to  develop  a  program  and  Its 
proof  simultaneously,  that  is,  by 
considering  the  proof  at  each  step  of  the 
program  design  and  implementation  process 
rather  than  writing  the  program  first  and 


then  attempting  to  prove  it.  In  short,  if 
we  are  to  prove  programs  of  significant 
size  and  complexity  with  current  methods, 
those  programs  must  be  designed  to  be 
proved. 

Programs  can  be  designed  to  be  proved 
because  current  verification  techniques 
are  perfectly  compatible  with  currently 
advocated  methods  of  program  construction 
(for  example,  the  concepts  of  structured 
programming,  levels  cf  abstraction,  and 
their  numerous  aliases).  One  can  verify 
each  elaboration  of  a  developing  program 
at  the  time  of  elaboration  rather  than 
wait  to  verify  only  the  final  version  of 
the  program.  The  use  of  this  approach 
should  result  In  a  structured,  modular, 
and  unders tandabl e  verification.  An 
encouraging  example  Is  the  verification 
C 2 3  of  a  structured  algorithm  of  several 
levels.  The  proof  follows  that  structure 
exactly.  Small  changes  to  the  algorithm 
will  mean  corresponding  small  changes  to 
the  proof. 

Currently,  It  Is  not  Intended  that 
the  program  construction  and  verification 
system  include  any  significant  automatic 
programming  or  code  synthesis  facilities. 
The  system  is  not  expected  to  aid  In 
selecting  an  algorithm  for  accomplishing  a 
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task  or  In  choosing  data  and  control 
structures.  The  human  programmer  still 
retains  primary  responsibility  for 
designing,  and  for  proving,  his  program* 
The  purpose  of  the  system  l  j.  to  provide  a 
set  of  facilities  that  make  it  possible 
for  the  programmer  to  interactively 
develop*  from  a  precise  specification  of 
his  problem,  both  a  program  and  a  proof 
that  the  program  solves  his  problem.  It 
Is  assumed  that  the  programmer  is  highly 
knowledgeable  both  I  n  hi s  problem  area  and 
In  the  methods  of  program  proof  supported 
by  the  system. 

The  system  focuses  on  providing  the 
programmer  with  three  fundamental  and 
Interrelated  capabilities:  program 
construction,  program  execution,  and 
program  verification.  The  program 
construction  part  of  the  system  provides  a 
basis  for  designing  the  program  on  a 
structured,  segment-by-segment  basis  while 
maintaining  the  integrity  c'  the  proof  as 
the  program  Is  expanded  and  modified. 

The  program  execution  capability  is 
supplied  by  an  Interpreter  that  provides  a 
sophisticated  debugging  tool  along 
conventional  lines.  By  this  means,  faulty 
programs  can  be  detected  without  using  the 
considerably  more  expensive  verification 


machinery.  The  verification  part  of  this 
system  Is  based  on  the  conventional 
inductive  assertion  method:  generate 

verification  conditions,  simplify  them, 
and  prove  them. 

The  spirit  of  tne  verification 
component,  as  well  as  the  entire  system. 
Is  to  provide  automatic  tools  where 
practical  and  to  rely  on  interactive 
capability  for  manual  Intervention 
otherwise.  This  philosophy  Is  motivated 
by  our  beliefs  that  for  real  programs, 
( 1 )  large  parts  of  the  total  proof  can  and 
should  be  done  automatically,  and  (2)  in 
the  foreseeable  future,  some  parts  wi  11 
have  to  be  done  manually. 

CURRENT  STATUS 

Our  currently  running  system  consists 
of  a  text  editor,  a  program  and 
specification  parser,  a  program 
Interpreter  capable  of  running  both  actual 
and  symbolic  data,  a  verification 
condition  generator,  a  simplification  and 
substi tut  ion  package,  and  a  theorem 
prover. 

The  program  verlf*  it  I  on  portion  of 
the  system  is  based  on  decomposing  the 
verification  task  as  shown  In  Figure  2.1. 
The  inputs  are  (1)  the  program  to  be 
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verified  and  (2)  the  specifications  and 
assertions  to  which  the  program  is  to  be 
shown  cons I  stent*  The  verification 
condition  generator  or  lemma  generator. 
Invoking  the  syntactic  and  semantic  rules 
of  the  programming  language,  reduces  the 


Specifications 
Program  (assertions) 


Figure  2.1  Decomposition  of  the  verification  task 


verification  task  to  proving  a  derived  set 
of  mathematical  lemmas;  the  program  itself 
has  essentially  been  eliminated.  Large 
segments  of  the  derived  lemmas  are  proved 
by  relatively  f trai ght forward  simpli¬ 
fications  and  Sv  ? stl tuti ons  Involving 
global  algebraic  facts,  global  Boolean 
facts,  and  problem-specific  facts.  The 
remaining  lemmas  are  then  passed  to  an 
interactive  theorem  prover  that  invokes 
global,  generally  useful  theorems  as  well 
as  problem- spec! f ic  theorems. 

The  human  user,  represented  by  the 
stick  figure,  can  guide  the  verification 
interactively.  He  is  an  Important 
component  of  our  verification  system--! n 
fact,  one  that  distinguishes  our  s/stem 
from  most  others.  Such  Interaction  is 
being  used  successfully  in  at  least  one 
theorem  prover  C3J.  If,  as  we  expect  (and 
arc  beginning  to  demonstrate),  the  human 
is  ieft  to  supply  to  the  system  only  a 
minimal  amount  of  crucial  advice  and 
hunches  to  complete  the  proofs  of  the 
remaining  lemmas,  tnen  this  will  be  an 
appropriate  and  cost-effective  use  of  the 
human  user  in  the  verification  task.  Of 
course,  ensurinc  that  the  system  does  not 
in  the  end  ask  the  user  to  do  what  he 
considers  too  obvious  is  a  nontrivial 
problem,  taking  the  human  an  important 
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component  seems  a  proper  response  to  the 
genuinely  open-ended  nature  of  the  facts, 
theorems,  and  deductions  needed  to  verify 
real  programs.  If  ve  wish  the  system  to 
be  abl  *  to  handle  a  particular  type  of 
reasoning  or  set  of  facts,  ve  can 
hopefully  add  the  appropriate  capability* 
In  the  meantime,  however,  the  system/human 
combination  can  together  verify  programs* 

Note  In  Figure  2.1  that  the  human  can 
advise  both  the  simplifier  and  the  theorem 
prover.  In  particular,  by  supplying 
additional  facts  and  theorems  to  be  used. 
He  can  also  change  either  the  original 
prooram  or  the  specifications,  or  both,  if 
that  seems  appropriate  in  light  of  any 
false  lemma  (i.e.,  a  counter-example  has 
been  found)  or  a  lemma  whose  truth  or 
falsity  cannot  be  determined  (i.e.,  the 
can't  tell  cjse). 

A  more  detailed  view  of  the 
verification  part  of  the  system  Is  shown 
in  Figure  2.2.  Input  programs  are  written 
In  an  interesting  subset  of  the  fre- 
quently-used  Algol -l Ike  language  Pascal, 
to  which  assertions  have  been  added. 
The  input  specifications  and  assertions 
are  written  as  (Ecolean)  expressions  of 
Pascal,  augmented  by  implication, 
equivalence,  and  limited  quantification. 


Because  function  calls  are  permitted  In 
expressions,  this  assertion  language  Is 
theoretically  adequate.  In  practice  it  Is 
somewhat  inelegant,  but  not  Inconvenient. 
Other  notations  for  assertions  are 
beginning  to  be  developed  and  Implemented* 

The  Input  is  converted  to  a  prefix 
representation  used  throughout  the  rest  of 
the  system*  One  use  Is  as  Input  to  the 
interpreter  for  Pascal,  permitting 
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Lemmas  sufficient  Algebraic 

to  verify  program  execution 


Figure  2.2  Overall  organization  of  currently 
running  verification  system 
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algebraic  execution,  in  addition  to  the 
usual  numeric  execution.  One  use  for  the 
algebraic  execution  is  to  assist  in  the 
(human)  construction  of  the  assertions 
needed  in  verification,  although,  of 
course,  some  program  construction 
strategies  suggest  the  assertions  will  be 
known  before  the  actual  program  code  is 
written.  The  interpreter  can  also  serve 
as  an  alternative  basis  for  a  verification 
condition  generator. 

The  oti.er  use  for  the  prefix 
representation  is  as  input  to  the 
verification  condition  generator,  the 
output  of  which  serves  as  input  to  the 
simplifier  and  to  the  theorem  prover 
(whose  function  and  use  were  described 
above).  The  verification  condition 
generator  is  based  directly  upon  the 
axioms  and  rules  of  inference  that 
constitute  the  definition  of  Pascal .  We 
also  have  available  a  standard  Pascal 
compiler,  an  interesting  convenience  but 
not  a  necessity  to  the  verification 
system. 

A  different  view  of  the  construction 
and  verification  system.  In  Figure  2.3, 
shows  additional  relationships  of  the 
components  and  emphasizes  the  outputs  of 
each. 


The  construction  and  verification 
system  is  procr ammed  in  Reduce  [4]  and  Is 
therefore  Lisp-based.  Besides  the  virtues 
of  programming  In  a  high-level  compilable 
language.  Reduce  provides  three  Important 
advantages.  First,  nearly  all  of  the 


program 

and 
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VERIFIED 

PROGRAM 


Figure  2.3  Oufpufs  from  component  of  program 
design  and  verification  system 
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simplification  and  substitution  is 
provided  with  minimal  effort  by  the 
exi stinc  Reduce  capabilities*  the 
remainder  is  provided  by  easily 
constructed  Reduce  procedures.  The 

pattern  -  match! no  capabilities  of  Reduce 
are  exploited  to  permit  the  easy  input  of 
additional,  user-def i ned  sinpl • fication 
rules.  Second,  Lisp  programs  written 
i ndependent 1 y  of  Reduce  can  be  made  part 
of  the  system;  this  capability  has  been 
exploited  to  advantage.  The  previouslv 
existing  verification  condition  gener¬ 
ator  [S]  was  imported  via  ARPANET  and 
essential iy  plugqed  into  the  system.  The 
interactive  theorem  prover  [3]  that  we 
have  incorporated  into  the  system  took 
more  effort  because  it  first  had  to  be 
converted  from  one  Lisp  system  to  another. 
Third,  because  Hearn  has  invented 
considerable  resources  in  making  the 
Reduce  system  available  on  a  wide  class  of 
computers  and  operating  systems,  the 
corresponding  availability  of  the 
verification  system  will  be  achieved 
merely  by  keeping  the  programming  of  the 
system  in  Reduce. 


Currently,  the  verification  system 
can  verify  an  interesting  class  of  small 
proqrams  from  the  program  verification 
1 i terature,  from  various  programming 
manuals  and  texts,  and  from  our  own  test 
examples.  furthermore,  the  use  of  such 
simple  structuring  notions  as  procedures 
and  functions  eases  the  verification  task. 
Although  this  system  has  not  yet  verified 
ail  of  the  programs  of  other  existing 
program  verifiers,  we  are  nevertheless 
encouraged  by  the  power  inherent  in  Reduce 
and  In  the  theorem  prover  that  we  have 
just  begun  to  exploit.  We  remain 
confident  that  our- system  will  be  able  to 
verify  such  programs  shortly,  and  that  the 
system  will  be  an  extremely  flexible  and 
valuable  asset  in  experimenting  with 
assertion  languages,  structuring  methods, 
and  proof  methods  for  verifying 
significant,  real  programs,  such  as  a 
compiler  for  Pascal,  an  editor,  parts  of 
the  verification  system  Itself,  or 
appropriate  application  programs. 
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INTRODUCTION 

The  Programming  Research  Instrument 
(PRIM)  project  has  created  a  fully 
protected  experimental  corouting  environ¬ 
ment  with  continuous  multiuser  access.  An 
ARPANEl-based  multiaccess  system,  PRIM 
allows  each  researcher  to  create  his  own 
specialized  computing  engine  capable  of 
being  changed  and  adapted  to  his  specific 
needs.  The  PRIM  hardware  and  software 
together  provide  a  working  environment  in 
which  the  user  can  implement  his  own 
computer  in  microcode  and  run  that  com¬ 
puter  in  his  target  program  environment. 
PRIM  can  be  used  to  explore  computer 
architecture,  language  development,  and 
special-purpose  processor  design — all  of 
especial  relevance  to  UoD  selection  and 
use  of  computer  equipment. 


The  PRIM  facility  makes  it  possible 
to  easily  simulate  new  hardware  archi¬ 
tectures  and  designs  in  microprogrammed 
software.  That  is,  software  can  be 
created  for  hardware  not  yet  available, 
and  hardware  designs  may  be  extensively 
used  and  changed  even  before  the  prototype 
stage  of  development  is  reached.  This 
should  both  cut  lead  time  and  improve 
decisions  connected  with  the  special- 
purpose  hardware  procurement  cycle. 

To  familiarize  potential  users  with 
the  operation  of  the  PRIM  system,  ISI  will 
provide  introductory  seminars  and  an 
extensive  documentation  package.  PRIM 
user  docurrentat  I  on,  consisting  of  an 
Overview,  User's  Guide,  MLP-900  Reference 
Manual,  and  GPM  Reference  Manual,  is 
nearing  completion  and  should  be  available 
to  interested  potential  users  by  mid-197^. 
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TMs  documentation  Is  currently  available 
Wa  the  ARPANET  at  I  SI.  directory 
PRIM. DOCUMENTATION.  The  pR1„  0vepv,ev  ^ 

already  been  published  and  distributed 
t,]*  Interested  Individuals  wT 1 1  be 
invited  to  a  user's  seminar,  scheduled  for 
June,  at  which  time  PRIM  will  be  operating 
In  the  environment  for  which  It  was 

gned.  ,si  personnel  will  continue  to 
be  available  to  assist  users  and  correct 
bugs  within  the  system  as  required. 

HARDWARE 

PRIM'S  hardware  system  is  based  on 
two  processors:  the  Digital  Equipment 
Corporation's  POP- I 0  and  the  STANDARD 
Computer  Corporation's  MLP-900  prototype 
processor  (see  Fig.  3.1).  ThePDP-lUand 
MLP-900  share  memory  as  dual  processors; 
the  MLP-900  Is  a  device  on  the  POP- 10  I/O 
bus  (see  Figure  3.2). 


PDP-1Q 

The  PDP-10,  connected  to  the  ARPANET 
runs  under  the  TENEX  time-sharing  syste, 
of  Bolt  Beranek  and  Newman.  Inc.  on  ; 
Paged  virtual  memory.  its  processor 
contains  256K  words  of  36-blt  memory.  The 
I/O  operations  performed  by  1FNEX  Include 
file,  terminal,  and  network  handling. 


swapping,  and  all  other  accesses 
peripheral  devices. 


to 
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MLP-900 

The  MLP-900  is  a  vert  I  cal -word 
mi  croproqrammed  processor  that  runs 
synchronously  with  a  A-MHz  clock.  it  is 
characterized  by  two  parallel  computing 
engines!  the  Operating  Engine  (OE),  which 
performs  arithmetic  operations,  and  the 
Control  Engine  (C£),  which  performs  con- 
trol  operations  (see  Figure  3.3).  The 
OE  contains  32  36-bit  general-purpose  reg¬ 
isters  for  operands  and  32  36-bit  mask 
registers  to  specify  operand  fields.  A  IK 
36-bit  high-speed  auxiliary  memory  is 
associated  with  the  OE.  The  CE  contains 
2S6  state  flip-flops,  a  16-word  hardware 
subroutine  return  stack,  and  16  8-bit 
pointer  registers. 


The 

MLP-900 

Is 

access! bl e 

on  1  y 

through 

the  POP- 

•10 

as  out  1 i ned 

above 

( i .e. ,  the  I /0  bus 

and 

shared  memory) 

;  no 

OPERATING  ENGINE 

CONTROL  ENGINE 

(I/O,  arithmetic,  logic) 

(Branches,  testing) 

General  registers 

Flip/flops 

32x36  bits,  R.0-R.37 

256x1  bits,  F , 0 - F . 377 

Auxiliary  memory 

Pointer  registers 

!Kx36  bits,  A. 0-A. 1777 

16x8  bits,  K0-P.17 

Mask  registers 

Subroutine  stack 

16x32  bits,  M.0-M.17 

16x  16  bits,  S.0-S.17 

CONTROL  MEMORY 

4Kx36  bits 

Figure  3.3  MLP-900  configuration 


provisions  have  been  made  for  direct 
connection  of  any  peripheral  devices. 

The  Introduction  af  a  microvisor 
state  has  been  of  major  importance  to  the 
PRIM  project.  Prior  to  this  project, 
little  had  been  done  toward  making  the 
multitude  of  available  microprogrammed 
processors  potentially  sharable  resources. 
This  Initial  experiment  goes  a  long  way 
toward  making  microprogrammed  processors 
widely  and  inexpensively  available. 

The  major  hardware  effort  was 

conducted  in  four  broad  areas: 

1)  Reconfiguring  the  MLP-900  mainframe 

for  necessary  expansion,  improved 
reliability,  better  cooling,  and 

Improved  power  distribution. 

2)  Interfacing  the  MLP-900  to  the  PDP-10 

(Including  I/O  and  memory  bus 

interfaces  and  a  paging  facility). 

Creating  a  microprogrammed  supervisor 
(microvisor)  state  within  the 

MLP-900,  with  facilities  for  pro¬ 

tection  of  the  privileged  resources 
and  appropriate  communication  to 
change  state. 

Enhancing  the  user  environment  within 
the  MLP-900. 
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The  modification  of  the  MLP-900  and  the 
Interface  to  TENEX  (Items  1,  2,  and  3) 
were  essentially  completed  during  the  last 
reporting  period;  the  details  of  these 
operations  can  be  found  in  Ref.  2. 

Enhancement  of  User  Envl  ronment. 

Although  this  year's  hardware  effort 
consisted  primarily  of  debugging  the 
MLP-900,  a  few  hardware  developments  are 
worthy  of  mention.  These  include  language 
boards.  Control  Memory  Address  Compare 
(CMADRC),  Virtual  Memory  Address  Compare 
(VMADRC),  auxiliary  memory,  and  streaming 
mode  transfers. 

As  originally  conceived,  the  language 
boards  were  to  perform  a  variety  of 
functions  for  the  MLP-900  relating  to  the 
interpretation  of  target  instructions. 
These  boarcis  were  to  be  designed  and 
uni  cue’ y  used  ior  specific  target  level 
lancuaoes,  one  board  per  language.  1  he 
functions  performed  simplified  and/or 
reduced  the  mini  steps  required  to  execute 
target  level  instructions.  The  concept  is 
being  modified  to  generalize  the  function 
of  the  language  boards  such  that  one  set 
of  language  boards  will  enhance  all  tarret 
level  languages  and  minimize  the  need  for 
redesign  and  change  of  language  boarcis 


throughout  the  life  of  PRIM.  Because  the 
functions  and  registers  required  by 
microvisor  Interaction  and  user  control 
are  protected,  two  types  of  language 
boards  have  been  designated^  trie 
Super visor  Language  Board  (SLB)  and  the 
User  Language  Board  (ULB).  The  SL3 
utilizes  language  board  outputs  for  task 
assignments,  page  faults  (communicating 
with  the  TENEX  system),  and  MLP-900  mode 
control.  The  ULB,  which  is  currently  a 
nul l  board,  passes  data  from  target  memory 
to  the  MLP-9CG  without  modification  or 
interpretation  but  will  grow  as  users' 
requirements  become  known.  All  the 
currently  required  ULE  functions  are  being 
performed  with  MINIFLOW  and  wi  1 1  be 
modified  ns  speed,  space,  and  loqic 
eventually  become  a  factor. 

1  he  compare  registers  VMADRC  ana 
CMADRC  (lb  bits  ana  12  bits,  respectively) 
have  been  implemented  as  user  debugging 
tools.  These  registers  can  be  loaded  and 
compare-crab  I  ec:  to  assist  the  user  when 
debugging  software.  One  register  operates 
at  the  MIMKLOW  (control  memory)  level, 
the  other  at  the  target  (main  memory) 

I  eve  1 . 

A  lu2A-wo rd  (36  bits)  200-ns 
auxiliary  memory  has  been  added  to  the  OE 
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to  be  i  sed  as  a  cache  or  scratchpad.  The 
senior  y  is  i  np  1  erented  with  a  Cooar 
Corporation  module  identical  to  that  used 
for  control  memory ,  and  the  memory  boards 
are  i  nterchangeabl  e  in  all  /’.LP-SLO 
memories  (control,  translator,  and 
auxi 1 i ary). 

The  stream! no  mode  (fast  block 
transfers)  from  the  PuP-IO  core  to  the 
MLP-900  is  operating  satisfactorily  at  an 
average  transfer  rate  of  330  ns  (never 
more  than  350  ns);  three-way  memory 
overlap  can  be  achieved.  The  design  oca l 
was  tc  maximize  the  speed  of  the  the 
context  swapping,  taking  advantage  of 
four-way  memory  overlap  capabilities  of 
the  PDP-1C  memory. 


The  GPM  compiler  was  esentially 
completed  in  ear  y  1973;  for  a  more 
detailed  account  of  its  development  the 
reader  should  consult  Refs.  3  and  ^ .  The 
major  effort,  of  this  year,  and  the  major 
emphasis  of  this  section,  is  the 
development  of  the  TEWEX  software  support 
and  the  microvisor. 

GPM  and  the  GPM.  compi  1  e 

GPM  is  a  high-level  machi  ne-or  i  ented 
language,  written  in  T ENEX  tlLISS,  desiqned 
explicitly  for  the  MLP-900.  As  a 
high-level  language,  GPM  offers  a  block 
structure  and  statement  syntax  similar  to 
PL/1  or  £LGGL.  The  specific  statement 
types  defined  in  GPM  are  generalizations 


SOFTWARE 

There  are  three  principal  items  of 
PRIM,  software: 

•  The  General  Purpose  Mi  croproaranmi ng 

Language  (GPM)  compi ler. 

•  The  /1LP-900  microprogram  supervisor 

( mi  crovi  sor  ). 

•  The  TEiNE X  MLP-9UG  programs,  i.e.,  tne 

MLP-9GU  driver  and  MLP-tXLL. 

The  basic  PRIM  software  architecture  is 
shown  in  Figure  3-**. 


PDP-10 


ML  P-900 


Figuie  3.4  Boii :  PRIM  softwore  a.chitecture 
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of  thr  actual  MLP-900  MINIFLOW  Instruction 
set;  -obstructs  completely  forelgr  to 
MlNJF^bW  (e.g„,  multiplication)  do  not 
appear  In  GPM.  As  a  simple  example  of 
MINIFLOW  generalization,  consider  that  the 
result  of  a  GEAR  (GEneral  ARithmetic) 
mlnlstep  may  be  shifted  left  or  right  only 
by  0,  I,  2,  4,  6,  8,  12,  or  16  bits;  In 
GPM,  any  shift  amount  may  be  specified, 
and  the  compiler  will  generate  multiple 
shi f ts  as  requi red. 

As  the  production  language  for  the 
MLP-900,  GPM  Is  constrained  to  satisfy 
many  of  the  usual  requirements  >f  an 
assembly  lanouane.  First.  there  is  a 

well-d2fined  subset  of  GPM  statements  that 
produce  exactly  one  mini  step  per 
statement;  the  sunset  is  capable  of 

generating  all  possible  ministeps. 
Second,  mu  1 1 i -mi ni s tep  statements  ao  not 
generate  implicit  side  effects;  for 

example,  a  complex  arithmetic  assignment 
that  requires  a  temporary  reqister  for  an 
intermediate  result  will  generate  a 
compile-time  error  unless  the  programmer 
Fas  explicitly  decJareo  some  register  to 
be  aval lable  as  a  temporary. 

The  GPM  compiler  is  successfully 

being  used  to  write  diagnostics  for  the 
MLP-900  and  test  user  software  (emulation 


of  a  POP- 10),  Experience  with  the 
compiler  reveals  that  minor  modi f Icat l ons 
and  suggested  speed  improvements  may  be 
required.  The  improvements  will  be 
considered  as  more  measurement  data  Is 
accumulated  and  specific  critical  code  is 
further  identified. 

MLP- 900  Mi crovi sor 

The  MLP- 900  mi croproor am  supervisor 
(microvisor)  is  a  small,  fully  protected 
resident  system  that  controls  the  MLP-900 
and  its  communication  with  the  PuP- 10.  It 
loads  and  unloads  the  user's  ML P-900 
context  upon  command  from  the  POP- 10, 
supports  paging  of  the  user  target 
program,  protects  main  memory  and  the  rest 
of  the  POP- 10  system  from  user  interpreter 
errors,  and  provides  the  interpreter  with 
a  few  services,  such  as  an  extended 
subroutine  stack  ana  calls  for  external 
communi cat • on.  (The  ri crovi sor  requires 
7$u  (octal)  woros  of  control  memory, 
including  its  Ac t i on  Request  locations.) 

i  he  microvisor  per  forms  the  functions 
normally  expected  of  an  operating  system, 
the  difference  being  that  it  l  *s  written  in 
microcode  and  supervises  the  execution  of 
microcode.  The  ni crovi sor  interacts  only 
with  the  user  microcode  and  the  TENtX  MLP 
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driver;  it  doer,  not  provide  any  facilities 
for--or  impose  any  restrictions  upon — the 
user  target  system.  User  microcode  is 
subject  to  the  restrictions  imposed  by  the 
user  mode  MLP-900  hardware. 

POP- I  0  Support  Programs 

The  POP- 1 0  TENEX  software  for  support 
or  the  MLP-900  consists  of  a  driver  to 
control  communication  with  and  sharing 
of  —  the  MLP-900,  and  a  subsystem 
(MLP-EXEC)  to  allow  Interactive  access  to 
the  MLP-900  for  a  user  at  a  TENEX 
terminal.  The  MLF  driver  and  its  T EM EX 
JSYS's  comprise  the  interface  to  the 
MLP-900  used  by  MLP-EXEC. 

The  TENEX  MLP-900  Driver.  As 
mentioned  above,  access  to  the  MLP-900 
from  a  TENEX  process  is  accomplished  via 
the  MLP  driver  in  TENEX.  The  MLP-900 
driver  is  the  extension  in  TENEX  of  the 
microvisor;  ail  communication  with  the 
MLP-900  goes  through  the  driver.  While 
new  microcode  “machines"  can  be  designed 
and  debugged  under  the  MLP-EXEC,  completed 
ones  will  work  directly  through  their  own 
terminal  subsystems,  which  will 

communicate  d.rectly  with  the  driver. 
Communication  with  the  driver  is 
accomplished  through  a  series  of  JSYS's 


which  mimic  (rouchly)  the  JSYS's  for 
subsidiary  fork  control.  The  two 
principal  elements  involved  in  creating 
and  running  the  MLP  are  the  MLP  context 
(the  user  microcode  together  with  ail  the 
MLP  registers)  and  the  target  system  upon 
which  the  context  is  to  operate.  The 
calling  process  must  build  both  before 
establishing  access  to  the  MLP. 

The  context  is  a  structure  that 
contains  ail  the  data  necessary  to  load 
the  MLP  and  beni n  (or  resume)  execution  of 
the  desired  microcode.  It  includes  not 
only  an  image  of  the  MLP-900  control 
memory,  bit  also  the  internal  MLP-900 

registers  and  some  cells  used  by  the 
driver  to  implement  MLP-900  communication 
with  the  POP- 10.  The  context  is  10  memory 
pages  (51 words)  lone,  and  must  begin  on 
a  page  boundary  in  the  caller's  address 
space. 

The  target  system  is  the  memory  upon 
which  the  MLP  context  is  to  operate.  It 
is  defined  as  a  TEN EX  fork  (or  process), 
either  tne  caller  or  a  subsidiary  fork 

established  solely  for  this  purpose. 

Typically,  the  target  system  fork  (SFORK 
or  SFRKV)  vi  il  never  be  started  on  the 
POP- 10;  it  exists  to  define  an  address 

space  for  MLP  execution. 
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To  protect  the  ISI  TENEX  system  and 
lessen  the  impact  of  MLP  debugging,  both 
hardware  and  software,  the  initial  version 
of  the  driver  has  been  implemented  almost 
entirely  as  a  normal  user  process  rather 
than  as  part  of  the  TENEX  operating 
system.  This  preliminary  driver  is  being 
used  in  debugging  the  entire  system, 
including  the  interfaces  between  the 
microvisor  and  the  driver,  and  between 
MLP-EXEC  and  the  driver.  While  the 
differences  oetween  preliminary  and  final 
driver  are  transparent  to  both  the 
microvir.or  and  the  user  microcode,  there 
are  so^e  unavoidable  differences  for  the 
calling  TENEX  process.  MLP- EXEC  is  aware 
of  the  differences,  and  handles  them 
pjoperly;  to  tie  user  of  MLP-EXEC,  the 
on  1  v  visible  difference  i  «.  that  the 
response  tire  is  longer. 

MLP-EXEC  ana  Its  Commands.  MLP -EXEC 
In  «  user  program,  called  via  TENEX, 
written  primarily  in  BLISS.  ihe  program 
basically  consists  of  two  modules!  the  1/0 
handler  (whicn  includes  tile  access  and 
target  memory  allocation)  and  the  de¬ 
bugging  facility  (NLP  DD1).  Hie  MLP-EXEC 
commands  assume  a  familiarity  with 
TENt/  Exec  commands;  a  subset  of  TENEX 
commands  is  irplcrcntcd  for  functions 
sirilar  to  those  of  the  IEmEX  Exec. 


MLP-EXEC  provides  an  environment  in 
which  the  user  at  a  terminal  can  compile, 
load,  execute,  and  debug  MLP-900  microcode 
in  a  manner  similar  to  that  used  for 
debugging  programs  on  the  POP- 10.  In 
addition,  he  can  create  and  debug  target 
programs  and  environments — although  these 
tools  must  be  provided  at  a  very  primitive 
level,  since  MLP-EXEC  cannot  know  the 
nature  of  the  target  environment. 

The  MLP- EXEC  “ready"  character,  ">," 
signals  the  user  to  enter  a  command. 
Commands  to  MLP-EXEC  can  specify  any  of 
several  types  of  actions! 

1)  Controlling  the  loading,  execution,  or 

oeouggi ng  of  the  MLP  context. 

2)  Controlling  the  loadina  ana  debugai ng 

of  the  tarr  2t  system. 

>)  Setting  up  the  input/output  files  for 
the  NLP. 

k)  Proviainq  access  to  tne  TcNEX  within 
rif'-LXcC  as  a  convenience. 

£1  I  the  commands  for  user  context 
r.ani  pu  lat  i  on  uegi  n  with  a  periou  (''.“j. 
fnese  include  LuA^,  klScT,  CONiMsOL,  kUN, 
SAVE,  GE1,  an’  LC T  commands.  All  of  the 
commands  for  the  target  system  begi n  with 
the  character  "/"  ann  use  standard  TtNcX 
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subsystems  In  responding  to  the  command 
(i.e.,  /LOAD  Invokes  the  standard  TENEX 
loader  to  load  a  relocatable  binary  file 
into  the  target  system's  address  space). 
These  Include  GET,  MERGE,  DDT,  SAVE, 
SSAVE,  and  RESET  commands. 

The  command  format,  key  words, 
arguments,  and  separators  are  Identical  to 
those  used  in  TENEX.  MLP-EXEC  prompts  for 
each  field  required  by  the  user's  command, 
and  the  escape  terminator  will  complete 
abbreviated  commands.  Additionally,  two 
characters  (Control  T  and  Control  C)  act 
as  commands  in  themselves  to  control  MLP 


execution 

and 

to 

provl de 

sta  tus 

I nfor mat i on 

on 

the  MLP.  Editing 

control 

characters 

are 

also 

included  tc 

>  edit 

command  key 

word? 

.  and 

arguments. 

User  1 nterpreter  and  Tar  net  Program 

The  user's  interpreter  is  a  program 
written  In  GPM  to  run  on  the  MLP-3n0;  it 
defines  a  (re-entrant)  MLP-900  control 
memory  Imaqe.  This  Image,  together  with 
all  the  nonpr i vi leged  registers  and 
flip-flops  within  the  MLP-90U,  comprises 
the  MLP-900  context;  user's  contexts  are 
loaded  and  unloaded  as  the  MLP  driver 
shares  the  MLP  among  different  users. 


The  context  defines  the  user's 
Interpreter  (or  target  machine)  and 
operates  upon  the  user  target  program  In  a 
totally  arbitrary  way.  The  only 
constraint  upon  the  target  program  is  that 
it  fit  into  a  5I2K,  36-bit  (virtual) 
memory  space. 

FUTURE  EFFORT 

The  ISI  TENEX  environment  currently 
includes  a  KA-10  and  a  KI-10  CPU,  one  as  a 
backup  for  the  other  In  providing  TENEX 
service  to  the  ARPA  user  community. 
Initially  the  PRIM  project  will  use  the 
backup  CPU  to  provide  the  flexibility 
required  by  the  development  effort  with 
the  user  interaction  without  jeopardizing 
the  service  operation.  The  Ki/KA  CPU  com¬ 
patibility  introduces  problems  requiring 
modifications  to  the  microvisor,  espe¬ 
cially  in  the  paqe  faulting  routine, 
which  will  be  perfermed  durinr  the  next 
few  months.  The  remaining  hai  dware 
efforts  are  to  investigate  faster  clock 
speeds  (currently  A  MHz)  and  to  design  the 
general-purpose  language  boards.  The 
system  integration,  documentation,  and 
software  debuorlng  is  currently  nearing 
con p let l on. 

The  major  effort  of  the  near  future 
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will  be  that  of  maintain!  no  the  PRIM 
facility  and  of  I  ndoctr  i  nat  i  no  users-  The 
introduction  of  users  via  the  ARPANET  will 
be  the  final  system  test  and  will  heip  to 
identify  possible  areas  of  improvement. 
Initially,  the  MLP-900  vi 11  operate  vi th  a 
single  user  vi th  locked  pages  of  target 
memory.  With  increased  confidence  and 
experience  the  PRIM  system  will  evolve 
into  the  time-shared  resource  origins  My 


specified.  User  interest  has  been 
expressed  by  rrliitary  services  interested 
In  emulation  of  CPU's  currently  in  the 
procurement  cycle,  by  researchers 
interested  in  direct  high-level  language 
Interpreters,  and  by  computer  science 
instructors  preparing  curricula  for 
microprogrammed  processor*  design.  PRIM 
should  be  supporting  one  of  these  users  by 
June  of  19/4. 
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INTRODUCTION 

This  project  has  developed  and  is 
continuing  to  refine  methodologies, 
techniques,  and  standards  for  the 
analysis,  tescinq,  and  evaluation  of  the 
protection  features  of  operating  systems. 
Its  qoal  is  to  provide  answers  to  the 
question  of  what  tests  and  procedures  can 
and  should  be  applied  to  operating  systems 
in  order  to  determine  (1)  to  what  extent  a 
given  system  meets  its  requirements  for 
preventing  unauthorized  or  improper 
operations  and  (2)  how  systems  can  best  be 
designed  and  implemented  to  reflect  such 
regul rements.  The  research  directly  sup¬ 
ports  the  software  security  requirements 
issued  by  DoO  security  policymaking 
agencies. 

Tne  Protection  Analysis  project  was 
formed  In  September,  1973  by  the  union  of 
the  Empirical  System  Study  and  Protection 
Theory  projects,  reported  last  year  as 


part  of  the  Software  Assurance 
project  [lj.  The  former  focused  on 
near-term  solutions,  while  the  latter  was 
a  more  deductive  approach  to  discovering 
more  complete  and  systematic  evaluation 
methods.  These  are  reported  separately 
below,  followed  by  a  report  of  activities 
of  the  Protection  Analysis  project  since 
September. 

EMPIRICAL  SYSTEM  SiUuY 

Durinc  19/2,  the  Empirical  System 
Study  group  at  ISI  devised  a  method  for 
finding  security  errors  in  operating 
systems  by  identifying  types  of  “error 
patterns*.  This  approach  was  based  on  the 
empirical  observations  that  (1)  the 
majori ty  of  errors  In  operating  systems 
can  be  categorized  using  a  limited  number 
of  generic  error  types  an  I  (2)  it  is 
easier  to  find  errors  by  ystematially 
searching  for  Instances  of  generic  error 
types  than  by  randomly  searening  for  logic 
f laws. 
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Ft  eld  Tests 

In  late  1972  a  test  was  made,  using 
the  Multtcs  operating  system  as  a  test 
subject,  to  determine  the  usefulness  and 
effectiveness  of  the  method.  As 
previously  reoorted  [I],  security  errors 
were  found,  and  the  method  was  shown  to  be 
effective.  A  second  test  was  conducted  In 
the  summer  of  1973  using  the  error  pattern 
approach,  again  using  /luitics  as  a  test 
subject.  The  purpose  of  this  test  was 
again  to  verify  the  error  pattern  approach 
and  to  accumulate  more  Information  on  its 
use.  Curing  this  test,  a  member  of  the 
Multics  staff  was  added  as  a  test 
participant,  having  been  briefed  on  the 
expected  error  patterns.  The  protocol 
used  for  the  te-  t  was  the  same  as  that 
reported  in  Ref.  I,  i.e.: 

■  All  system  Information  was  made 
available  to  the  test  participants 
prior  to  the  test. 

*  The  system  being  tested  was  not 

modified  during  the  test. 

^  Proposed  errors  were  verified  by 
logical  analysis  and  not  by  writing 
or  runnlna  programs  to  exploit  the 
errors  on  live  systems. 


The  purpose  of  the  protocol  was  both  to 
expedite  the  test  and  to  eliminate  any 
possible  “garni ng“  situations  in  which 
systems  personnel  could  retroactively 
alter  the  system  to  disguise  or  eliminate 
f au  1  ts. 

The  goal,  vnlch  was  to  find  a  system 
error  usl ng  the  above  procedure,  was 
Immediately  achieved.  A  design  error  In 
Multics  affecting  operating  system 
security  was  discovered,  necessitating  a 
redesign  and  reprogramming  of  portions  of 
the  system.  The  error  was  reported  to 
both  Mi  ind  Honeywell,  and  changes  are 
currently  being  made  to  correct  It.  The 
results  of  this  and  the  previous  test,  as 
well  as  insights  into  the  use  o,  error 
patterns,  have  formed  the  basis  for  an 
automated  protection  evaluation  system 
based  on  generic  error  types,  which  is 
described  below. 

Encapsulation 

Enormous  sums  are  presently  invested 
in  computing  equipment  and  operating 
system  software.  The  neeo  for  security  in 
those  systems  is  strongly  felt  In 
government  and  business  as  well  as  in  the 
military.  The  problem  Is  intensified  by 
the  current  unreliable  state  of 
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Information  controls  In  contemporary 
systems. 

Tck.ay  a  certlflably  secure  multiuser 
operating  system  docs  not  exist.  No 
operating  system  has  been  able  to 
withstand  malicious  attacks  by  skilled 
penetrators.  Retrofitting  these  systems 
(in  the  general  sense  of  repairing  the 
respective  operating  systems  in  all  their 
various  versions)  is  an  enormous  task,  not 
well  understood.  To  date,  all  such 
attempts  have  failed.  Even  systems 
created  with  security  as  a  major  design 
parameter  have  been  easily  penetrated.  Tn 
general,  retrof 1 ttl ng  the  mul 1 1  pi e 
versi  ons  of  >/ar  i  ous  operat i  ng  systems  by 
revl si ng  the! r  code  i s  i mpracti cal . 

Nevertheless,  the  security  problem  of 
existing  systems  is  important  and  will  not 
diminish  in  the  coming  years.  The  only 
solution  now  available  to  those  instal¬ 
lations  requiring  reliable  protection 
has  been  physical  isolation^  to  have 
separate  operating  systems  for  each 
security  category  or  level  and  run  them 
sequentially.  For  the  military,  a 
separate  operating  system  is  required  for 
each  of  the  four  security  levels.  For  the 
typical  commercial  Installation,  separate 
operating  systems  might  be  required  for 


payroll,  accounts  receivable,  and  general 
computing.  A  considerable  amount  of 
useful  machine  time  is  thus  wasted 
changing  systems,  rigid  schedules  must  be 
established,  and  sharing  can  be  achieved 
only  through  off  line  procedures, 
controlled  admi nstrati vel y. 

The  Empirical  System  Study  group  has 
developed  an  approach  to  the  security 
retrofit  problem  for  batch  and  remote  Job 
entry  (RJE )  systems.  It  Is  fairly  simple 
and  appears  economical;  In  addition,  the 
same  solution  will  provide  certifiable 
security  for  a  variety  of  manufacturers, 
computers,  and  operating  systems.  A  small 
minicomputer  controlling  several  banks  of 
switches  is  added  to  a  currently  existing 
configuration.  These  switches,  which  are 
placed  in  the  read/write  cl  ret i t  of  the 
peripheral  devices,  allow  the  minicomputer 
to  enable  or  disable  those  devices  (see 
Fioure  L.l).  As  in  the  case  of  virtual 
machine  systems,  each  encapsulated  user 
program  will  run  with  Its  own  operating 
system.  Depending  on  *>hich  operating 
system  is  currently  in  control  of  the 
production  CPU,  the  minicomputer  sets  the 
device  switches  accordingly,  so  that  the 
operating  system  can  physically  access 
only  appropriate  devices.  For  many 
existing  peripheral  devices,  such  switches 
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already  exist.  Estimates  of  the  cost  of 
the  above  encapsulation  unit,  including 
the  one-time  expense  of  system  design  and 
software  verification  as  well  as  the 
per-i nsta 1 1  at i on  expenditure  for  hardware, 
appear  to  be  eminently  reasonable. 

The  unit  has  several  attractive 
aspects.  Original  software  can  rur 
without  changes,  read-only  sharing  is 
provided  and  scheduling  flexibility  is 
increased.  Most  important,  the  software 


relevant  to  security  is  small  enough  that 
its  security  properties  can  be  formally 
verified;  also,  its  code  is  isolated  and 
protected  from  ary  other  software.  In 
this  fashion,  encapsu 1  at j  on  provi des  a 
certj  f iable,  reliable  means  for  multi  1 evel 
computer  secur  j  ty  on  exj  st i ng  batch 
systems,  possibl y  end l ng  thei r  retrof i t 
problem.  This  work  is  documented  in  more 
detai 1  in  Ref.  2. 
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To 

unit  record 
equipment 


Figure  4.1  Security  encapsulation  unit 


Protection  is  that  central  aspect  of 
computer  security  concerned  with  the 
control  of  operations  within  the  domain  c.f 
the  operating  system,  i.e.,  by  internal 
processes  on  internal  objects.  Although 
the  security  of  a  computer  system  depends 
on  the  correctness  and  completeness  of  its 
protection  mechanisms,  there  Is  a 
well-known  shortage  of  methodologies 
either  for  designing  these  mechanisms  or 
for  evaluating  existing  systems  for 
errors. 

The  goal  of  the  Protection  Theory 
project  was  to  design  and  develop  an 
evaluation  method  that  would  be  both 
thorough  and  systematic,  properties  that 
current  methods  lack.  A  method  specific 
to  the  protection  problem  Is  likely  to 
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become  cost-effective  sooner  than  tools 
Intended  for  the  verification  of  computer 
programs  in  general  [3J.  The  project  was 
begun  in  January  1973,  starting  with  an 
extensive  survey  of  the  field  to  determine 
the  current  state  of  evaluation 
methodology  and  the  boundaries  of  the 
protection  problem.  The  work  reported 
here  was  concerned  wi th  two  major  areass 

1)  Outlining  an  evaluation  scheme.  The 

result  Is  an  independent  policy-based 
(1PB)  evaluation  method,  utilizing 
concepts  from  the  field  of  structured 
des i gn. 

2)  Formulating  the  protection  problem  and 

deriving  a  notational  basis  for  the 
expression  of  protection  policy.  A 
level-independent  formulation  was 
de^l ved. 

The  I pjj  Evai  nation  Method 

From  the  point  of  view  of  structured 
design  [4],  system  development  is  a 
process  of  transformations  on  some 
hierarchy  of  objects  and  specifications  of 
Increasing  concreteness  and  decreasing 
abstractness  toward  the  lower  levels, 
ordered  by  the  relation  of  representation 
(see  FI  pure  4.2). 


With  respect  to  protection,  the  more 
abstract  elements  are  those  of  policy  and 
the  more  concrete  those  of  mechani sm.  If, 
during  development,  all  the  represen¬ 
tational  relations  were  maintained  ex¬ 
plicitly,  the  protection  mechanisms  of  a 
target  system  could  be  evaluated 
constructively.  Otherwise,  assuming  that 
the  elements  at  some  level  cf  policy 
(Psys)  are  stated  as  explicitly  as  those 
at  the  mechanism  level  (Mays),  evaluation 
must  consist  of  an  independent  comparison 
of  Msys  with  Psys--hence  the  name  "IPB". 


® — -0  :  "X  is  (partially)  represented  by  Y" 


Figure  4.2  Representational  hierarchy 
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Such  a  method  requires  a  separate 
hierarchy  (see  Figure  A. 3)  whose  ordering 
relation  is  one  of  logical  Implication 
from  policy  to  mechanism.  An  Input  to 
such  an  evaluation  Is  the  set  Psys  of 
target  system  policy.  The  implications 
define  a  mapping  that  produces  a 
corresponding  set  of  reference  speci¬ 
fications  (Mref)  at  the  mechanism  level, 
with  which  Msys  can  be  compared  for 
correctness.  If  the  IPB  method  is  to  be 
applicable  to  a  variety  of  systems,  thi 
domain  of  IMPL  must  be  a  collection  of 


Figure  4.3  IPB  evaluation  scheme 


protection  policies  that  encompasses  the 
policies  of  all  those  systems,  and  its 
range  must  be  a  generalized  set  of 
protection  mechanisms,  such  as  that 
proposed  In  Ref.  5,  suitable  to  enforce 
them.  A  major  difficulty  Is  that  In  order 
to  compare  Msys  with  Mref,  the 
system-specific  description  of  the  former 
must  first  be  "normal  I  zed u  1 nt^ 

generalized  terms. 

Pol  1 cy  and  i ts  Express,  on 

1  hough  many  protection  schemes  and 
models  exist  at  the  mechanism  level, 
little  work  has  been  done  at  the  policy 
level,  r.o  that  the  explicit  basis  needed 
for  IPB  evaluation  is  missing.  The 
essence  and  boundaries  of  the  protection 
problem  are  not  readily  apparent.  Among 
many  formulations,  the  one  most 
appropriate  from  a  number  of  standpoints 
Is  that  protect! on  i s  the  prevent  I  on  of 
uni  ntendid  use  of  certal  n  (protected) 
objects,  which  translates  In  more 
concrete  terms  Into  the  following- 

■  The  attachment  to  each  protected  object 
(explicitly  or  implicitly)  of  a 
condi t I onal  governing  Its  Involvement 
in  certain  operations. 
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■  The  prevention  of  .>uch  an  operation 
when  the  conditional  evaluates  to 
false. 

An  operation  Is  a  combination 
|x,W,Y|  where  X  Is  a  process,  W  Is  an 
operator,  and  Y  Is  the  set  of  operands  in 
the  application  of  W  by  X.  Any  of  these 
may  be  protected  objects.  Pre'entlng  the 
operation  {x,W,y}  means  either  pre¬ 
venting  the  selection  of  W  by  X  to  form 
activation  Wx  or  preventing  the  binding  of 
one  or  more  elements  of  Y  to  either  W 
(static)  or  Wx  (dynamic). 

Taken  at  the  mechanism  level,  this 
formulation  exhibits  the  key  role  of 
primitive  linking  and  binding  operators, 
vhich  must  enforce  all  occurring 
conditionals.  For  the  sake  of  economy, 
cctual  operating  systems  severely  restrict 
the  generality  Inherent  in  this 
formulation  and  also  make  heavy  use  of 
stored  representations  of  the  results  of 
condition  evaluations,  e.g.,  in  the  form 
of  “capabi 1 1  ties". 

However,  because  the  concepts  of  this 
formulation  can  be  interpreted  at  any 
level  of  representation.  It  Is  also 
veil-suited  to  be  the  basis  for 
specifications  at  the  policy  level.  This 
is  demonstrated  in  Ref.  4. 
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In  September  1973,  the  Empirical 
System  Study  and  Pr^  action  Theory 
projects  began  a  study  o(  ways  In  which 
their  complementary  approaches  to 
protection  evaluation  could  be  combined 
into  a  single  method,  with  the  empirical 
techniques  of  the  former  applied  to 
achieving  the  goals  of  the  latter.  The 

was  influenced  by  three 
observations* 

1)  The  security  community  lacks  a 

product i on  evaluation  tool.  Such  a 
tool  must  be  exportable,  requiring 
for  its  application  only  a 
familiarity  with  the  target  system 
rather  than  a  high  level  of  expertise 
In  evaluation  techniques;  rel 1 abl e. 
finding  consistently  all  errors  of 
the  types  covered;  and  economica i . 
not  requiring  large  evaluation 
projects  or  tooling-up  phases.  These 
attributes  imply  that  such  a  tool 

will  be  largely  automated  or 
computer-assi sted. 

2)  There  is  currently  no  known 

organized  effort  to  collect  and 

analyze  protection  errors  detected 
durinq  various  evaluations  of 

existing  operating  systems.  Such  an 
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effort  could  have  significant  value 
to  the  computer  security  field,  both 
In  facilitating  future  evaluation 
efforts  and  In  Identifying  classes  of 
errors  to  be  avoided  In  the 
development  of  future  systems. 

3)  Protection  errors  do  fall  Into 
distinct  classes  or  "patterns. “ 

Guided  by  these  observations,  the 
study  focused  on  the  way  In  which  the 
output  of  protection  evaluations  (I.e., 
errors  and  their  patterns)  can  be  utilized 
as  feedback  In  the  development  and 
Improvement  of  an  evaluation  method 
itself.  The  result  was  the  design  of 
a  systematized  error-driven  evaluation 
scheme  t^at  utilizes  the  output  of  error 
analysis  both  directly,  to  govern  the 
evaluation  process,  and  indirectly,  to 
Increase  the  comprehensiveness  of  the  tool 
based  on  this  method.  The  tvo  projects 
merqed  Into  the  Protection  Analysis 
project,  using  the  collection  and  analysis 
of  protection  errors  as  the  immediate 
phase  In  the  development  of  the  e'dluation 
tool . 

Error  and  Pattern  Processi ng 

This  work,  which  began  in  early  1^7^, 
consists  of  the  following  activities* 


Error  Col lecti on.  The  primary  Input 
Is  an  "error  base"  consisting  of  informal 
descriptions  of  protection  errors 
—  detected  as  well  as  potent!  al  —  both 
contributed  by  evaluation  personnel  and 
gleaned  from  the  literature  and  other 
sources.  In  addition  to  the  Empirical 
System  Study  project  reported  above, 
current  sources  include  Project  KISOS  at 
Lawrence  Livermore  Laboratory,  the 
Computer  Systems  Research  Group  at  MIT, 
and  a  Security  Analysis  Group  at  The  Rand 
Corporati on. 

Error  Anal ysi s.  The  analysis 

proceeds  in  two  steps*  identification  of 
t^o  raw  pattern  and  identification  of 
fea»ures.  The  raw  pattern  is  the 
(minimal)  set  of  conditions  that  together 
constitute  a  possible  error*  either  those 
holding  for  the  operating  system  as  a 
whole  or  possible  sequences  of  actions 
that  can  occur  more  locally.  "Raw*1  means 
described  in  terms  of  a  particular 
operating  system  or  line  of  systems. 
Features  are  the  individual  conditions  of 
the  raw  error,  as  well  as  the  operating 
system  entities  they  Involve.  The  feature 
terminology  becomes  the  technica? 
vocabulary  of  the  pcoject. 
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Class! f I  cation  and  General i zatlon. 
These  tvo  activities  are  closely  related. 
Each  raw  pattern  is  compared  with  others 
in  the  current  set  „o  determine 
differences  and  similarities.  As  -he  set 
grows,  a  grouping  or  class! f ’cation 
occurs,  with  the  patterns  In  each  group 
seen  as  Instances  of  some  generalized 
pattern,  described  in  correspondingly  more 
abstract  terms.  As  this  process 
continues,  generalized  patterns  In  turn 
become  associated  with  still  more  general 
patterns,  resulting  In  a  hierarchy  with 
the  most  general  and  abstractly  described 
patterns  at  the  upper  levels  anc?  the  most 
specialized  and  concrete  ones  at  the  lower 
I evel s. 

Data  Management .  The  collection  of 
raw  errors,  the  hierarchy  of  patterns,  and 
the  glossary  of  features  will  be 
represented  as  a  computerized  da'.a 
base  In  such  a  way  that  classifying  aru 
generalizing  activities  can  be  carried  cut 
efficiently.  The  following  retrieval 
functions  1 1  be  imp! ement ed: 

•  The  retrieval  of  error  description, 

pattern  description,  or  feature 
definition  by  name. 

•  The  generalizing  pattern  of  a  gh«n 

error  or  pattern,  respectively. 


■  The  errors  or  patterns  of  which  a 

given  pattern  Is  a  generalization. 

■  The  errors  or  patterns  In  which  a 

given  feature  occurs. 

The  facilities  of  ISl's  TtNEX  operating 
system  will  be  used  to  maintain  this  data 
base. 

The  Error-Dr  I  vert  Evaluation  Method 

Protection  evaluation  is  regarded 
here  as  a  two-step  process!  normalization 
and  comparison.  The  first  Is  the 
identification,  extraction,  and  formalized 
description  of  tne  protection  aspect, 
which  is  qeneraily  embedded  in  the  large 
and  complex  volur.2  of  Information 
representing  a  target  operating  system. 
The  second  is  a  compari son  of  the 
n  realized  protection  description  with  a 
given  set  of  reference  Information  to 
determine  the  presence  of  errors. 

In  the  error-driven  scheme,  these 
steps  are  directed  by  the  output  of  the 
error  and  pattern  processirj  activity  (see 
Figure  4.4).  Norma  1 1 zat I  on  Is  directed  by 
the  generalized  feature  set.  It  is 
essentially  a  systematic  search  of  the 
target  system  for  Instances  of  the 
generalized  features.  This  Is  basically  a 
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Class! f I  cation  and  General  I zat I  on* 
These  two  activities  are  closely  related. 
Each  raw  pattern  Is  compared  with  others 
In  the  current  set  to  determine 
differences  and  similarities.  As  the  set 
grows,  a  grouping  or  classification 
occurs,  with  the  patterns  In  each  group 
seen  as  instances  of  some  generalized 
pattern,  described  In  correspond! ngl y  more 
abstract  terms.  As  this  process 
continues,  generalized  patterns  In  turn 
become  associated  with  still  more  general 
patterns,  resulting  In  a  hierarchy  with 
the  most  general  and  abstractly  described 
patterns  at  the  upper  levels  and  the  most 
specialized  and  concrete  ones  at  the  lower 
1 evel s. 

Data  Management.  The  collection  of 
raw  errors,  the  hierarchy  of  patterns,  and 
the  glo  sary  of  features  will  be 
represented  as  a  computerized  data 
base  in  such  a  way  that  classifying  and 
generalizing  activities  can  be  carried  out 
efficiently.  The  following  retrieval 
functions  wl \\  be  Implemented: 

•  The  retrieval  of  error  description, 

pattern  description,  or  feature 
definition  by  name. 

•  The  generalizing  pattern  of  a  given 

error  or  pattern,  respectively. 


■  The  errors  or  patterns  of  which  a 

given  pattern  Is  a  generalization. 

■  The  errors  or  patterns  In  which  a 

given  feature  occurs. 

The  facilities  of  ISl's  TcNEX  operating 
system  will  be  used  to  maintain  this  data 
base. 

The  Error-Driven  Eva  1  uat  I  or.  Method 

Protection  evaluation  Is  regarded 
here  as  a  two-step  process:  normal  I zatl on 
and  comparison.  The  first  Is  the 
identification,  extraction,  and  formalized 
description  of  the  protection  aspect, 
which  is  generally  embedded  In  the  large 
and  complex  volume  of  Information 
representing  a  target  operating  system. 
The  second  is  a  comparison  of  the 
normalized  protection  description  with  a 
given  set  of  reference  Information  to 
determine  the  presence  of  errors. 

In  the  error- dr  I ven  scheme,  these 
steps  are  directed  by  the  output  of  the 
error  and  pattern  processing  activity  (see 
Figure  L.L).  Normal  I zatlon  is  directed  by 
the  generalized  feature  set.  It  Is 
essentially  a  systematic  search  of  the 
target  system  for  instances  of  the 
generalized  features.  This  Is  basically  a 
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manual  process,  but  can  be  computer- 
assisted  by  means  of  a  program  similar  to 
computer-assisted  Instruction.  Compar¬ 
ison  is  directed  by  the  general i zed 
pattern  set;  it  is  a  search  of  the 
normalized  desclption  for  combinations 
matching  any  of  the  given  error  patterns, 
a  process  that  can  easily  be  automated. 
The  output  is  a  list  of  error  indications. 

The  error-driven  method  is  *m!lar  to 
the  IP6  method  described  under  otection 
Theory  above  i n  that  a  normalized 


Figure  4.4  Error-driven  evaluation  process 


description  of  the  otection  mechanisms 
of  the  target  system  is  compared  with  a 
set  of  reference  information.  The  most 
important  difference  is  that  vi th  the  IPB 
method  the  reference  information  is  the 
complete  set  of  generalized  mechanisms 
logically  Implied  by  the  stated  policy 
of  the  target  system,  so  that  the 
completeness  and  consistency  of  the  target 
mechanisms  can  be  determi nea.  With  the 
error-driven  method,  only  errors  of  the 
types  represented  by  the  given  patterns 
vi I  I  be  detected. 

The  advantages  of  the  error-driven 
method  are  the  fol loving; 

■  It  systematically  capitalizes  on 

accumulated  protection  evaluation 
exper i ence. 

•  it  is  applicable  In  the  short-term 

future  as  a  standard  evaluation  tool. 

■  As  the  error  and  pattern  processing 

activity  continues  and  Its  scope 
expands,  the  comprehensiveness  of  the 
method  increases  correspondingly. 

•  Because  of  the  Insights  gained,  the 

error  and  pattern  processing  activity 
Is  also  valuable  as  a  contribution  to 
protection  theory  and  to  the 
development  of  the  IPB  method. 
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especially  In  Identifying  different 
protection  policies  and  understanding 
their  implications.  The  error-driven 
evaluation  method  provides  a  pro¬ 


duction  tool  for  testing  operations 
that  Is  suitable  for  use  as  a  test 
standard. 
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INTRODUCTION 

This  project  explores  the  use  of 
advanced  corn  titer  and  communi  cat  i  on 
techniques  In  military  environments.  The 
use  of  packet-switched  digital  network-  to 
provide  a  messaoe  handlino  service 
(exemplified  by  the  ARPANET)  has  immediate 
and  'ianif leant  usefulness  to  the  military 
community.  The  possible  applications  of 
such  a  service  have  served  as  the 
principal  focus  of  the  work  to  date. 

Current  military  communications 
systems  use  the  Autodin  system  to  handle 
formal  messages  at  electronic  speeds 
between  command  communications  centers. 
However,  manual  message  delivery  from  the 
communication  center  to  the  addressee 


typically  requires  from  several  hours  to 
an  entire  day.  Preparing  a  message  at  the 
origination  point  can  involve  hours  of  an 
action  officer's  time  (and  several  days  of 
total  elapsed  time)  to  obtain  the 
necessary  approvals,  each  of  which  may 
require  mod i f I  cat i on  of  the  message.  This 
coordination  of  messages  generally  has  to 
be  done  in  person,  which  consumes  large 
amounts  of  time.  In  fact,  nearly  all 
communication  about  classified  material 
must  be  handled  in  this  manner  because  of 
the  lack  of  secure  telephones. 

A  specif!^  example  of  such  an 
environment  was  the  object  of  a  study 
performed  by  ISi  in  the  spring  of 
1973  [lj,  Investigating  the  possible 
application  of  network  technology  to  the 
CUTCO  (Consol i dation  of  Teleccmmunicati ons 
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on  Oahu)  program.  COTCO  Is  a  OoO  effort 
to  improve  military  coMOunl  cations  on 
Oahu.  The  ISI  report  transmitted  via  ARPA 
to  the  Joint  Chiefs  of  Staff  recommended 
that  the  present  largely  manual  message 
transmission  system  be  replaced  by 
ai  Interactive  computer-based  system 
providing  direct  wrl ter-to-reader  service 
for  some  6000  action  officers  on  24 
ml  1 ! tary  bases. 

The  system  proposed  was  based  upon  an 
ARPA- like  network  connecting  2000  widely 
dlstrlbutvu  CRT  terminals  to  five  nessage 
processing  computers.  Such  a  system  would 
not  only  Improve  ?xl sting  services  but 
also  provide  several  new  capabilities  as 
veils  informal  communication  channels  to 
aid  In  conducting  everyday  business! 
faster  coordination  of  forma!  messages 
transmitted  via  Autodln;  and  broad  support 
services  related  to  communl cat  I ons,  such 
as  facilities  to  file  and  retrieve 
messages  by  user-defined  subject  titles, 
suspense  (tickler)  files  for  action,  and 
automatic  message  status  reports.  A 
mechanism  for  automatically  creating 
duplicate  flies  was  proposed,  as  well  as 
dual  connections  between  the  host  computer 
and  the  Intermediate  Message  Processors 
(IMPs),  so  that  no  equipment  failure  could 
interrupt  communications  to  a  large 


segment  of  users.  Actual  Installation  of 
a  test  model  of  the  system  on  Oahu  was 
proposed  to  prove  the  feasibility  of  the 
approach. 

The  Navy,  which  has  been  assigned  the 
task  of  Implementing  the  COTCO  program, 
currently  has  the  ISI  plan  under 
consideration.  Interest  has  been 
expressed  In  performing,  with  the 
cooperation  of  ARPA,  a  test  of  an 
Interactive  system  such  as  the  one 
proposed. 

1 SSUES  FOR  IMPLEMENTING  AN  AUTOMATED 
MESSAGE  SERVICE 

In  the  meantime,  the  Command  and 
Control  Message  Processing  Technology 
(CCMPT)  project  has  addressed  the  Issues 
Involved  In  the  Implementation  of  auto¬ 
mated  message  handling  services  for  other 
military  environments  besides  COTCO.  The 
goals  of  such  systems  are  the  following- 

■  Enhance  the  current  formal  message 

service. 

■  Provide  an  Informal  message  service. 

■  Enhance  current  off-line  message 

handling  (letters  and  reports). 

■  Enhance  functions  that  support  message 

handling  (file  retrieval,  suspense 
files,  etc.). 
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I  n 

order  to 

achl eve 

the  sort 

of 

system 

envl si oned. 

It  Is 

necessary 

to 

provl de 

the  foil  owl 

ng  basic 

components 

and 

a ttrl butes: 

■  Core-system  hardware  arch! tecture  that 

serves  as  the  foundation  for  building 
the  service, 

■  Core-system  software  architecture  and 

programs  whose  facilities  are  easy  to 
learn  and  operate  by  i sers  unfamiliar 
with  computers# 

■  Application  software  that  performs  the 

functions  required. 

■  Reliability  of  service. 

•  Secnr I ty  of  data. 

A 1 1 hough  eventually  the  system  must 
Incorporate  all  of  these  considerations 
simultaneously,  current  research  Is 
Investigating  them  Independently.  The 
form  of  the  core-system  hardware 
architecture  exists  today  within  the 

ARPANET,  although  the  specific 

Implementation  does  not  meet  the 

reliability  and  security  criteria  for  a 
military  environment.  Most  cf  the  other 

Issues  have  only  partial  solutions  at  this 
time;  research  programs  directed  toward 
completing  these  solutions  are  being 
Identified  or  are  under  way. 


HAROWARE  ARCHITECTURE 

The  core  system  must  allow 
Interactive  response,  connection  to  many 
terminals  at  distant  sites,  and  processing 
power  for  the  message  service.  The  system 
architecture  Is  '■hown  In  Fig.  5.1. 
Terminals  connect  to  Terminal  Interface 
Processors  (TIPs;  like  those  In  the 
ARPANET.  TIPs  Interconnect  through 
high-speed  (e.g.,  50-kb)  communication 
lines.  This  arrangement  of  TIPs  serves  as 
a  distributed,  packet-swl tched,  store- 
and-forward  network.  Through  this  network 
the  terminals  have  access  to  several 
message  processors  that  supply  the  message 


ser vl ce 

functions. 

In 

principle 

any 

message 

processor 

on 

the 

networ  k 

can 

provide 

that  service 

as 

long 

as  1 1 

can 

access  the  user's  files  (which  reside  on 
more  than  one  message  processor). 

Also  shown  connected  to  the  network 
In  Fig.  5.1  are  the  sped  a  I -f unctl  on 
computers  INT  and  WWMCCS.  These 

Illustrate  the  way  this  message  service 
permits  Interface  to  external  networks 
(INT  Interfaces  to  Autodln)  and 
task-oriented  systems  (WWMCCS  Is  a 
sped  a  1 -purpose  convnand  and  control 
computer  system).  By  extending  this 
concept  to  Include  other  networks  and 
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AUTODIN  SWITCH 


Figure  5.1  Abbreviated  block  diagram  of  proposed  comirvjnication 
system  architecture. 


SOFTWARE 


other  task-oriftnted  computer  systems,  a 
necbanism  is  provided  for  integrating  into 
a  sinole  framework  the  multitude  of 
independent  systems  being  built  in  the 
mi  1  i tar v  today. 

In  this  scheme  a  terminal  always 
talks  to  and  through  a  message  processor. 
If  the  user  engages  in  a  conversation  with 
another  terminal  or  a  special  purpose 
computer,  all  of  the  message  processor 
functions  (editor,  files,  etc.)  are  still 
at  his  f i noer t I ps - 

This  architecture  provides  redundant 
paths  for  nessaoeJf  which  results  in  hi  oh 
i nht rent  reliability.  Its  flexibility  in 
ter~s  of  sea*,  ability  and  performance 
opt i mi znt I  on  rakes  the  approach  extremely 
applicable  to  the  military  community. 

SOFTWARE*  ARCHITECTURE 

The  software  architecture  provided 
must,  of  course,  support  the  functional 
operation  of  an  interactive  message 
handling  service.  This  service  must 
possess  good  response  time  and  be 
consistent  and  easy  to  use.  It  must  also 
provide  data  security  and  highly  reliable 
servi ce. 

The  CONNECT  system  being  developed  at 


1SI  Is  a  human- factor s-or i ented  research 
system  capable  of  encompassing  a  message 
service  such  as  that  described  here. 
CONNECT  is  discussed  in  more  detail  in 
Section  6  of  this  report.  briefly, 
however.  It  is  an  on-line  comuni  cat  ion 
service  designed  to  interact  with  its 
users  in  a  way  that  seems  natural  to  them. 
It  gives  the  appearance  of  personalized 
service,  makes  extensive  use  of  tutor 
facilities  to  guide  the  user,  and  employs 
a  consistent  language  for  interaction  that 
is  easy  to  learn  and  use. 

The  application  program  for  an 
interactive  message  service  is  that  part 
of  the  total  enterprise  most  apparent  to 
its  users  as  they  employ  it.  To 
understand  users'  needs  in  sufficient 
detail,  a  team  of  four  IS1  staff  members 
spent  three  days  at  CINCPAC  headquarters 
at  Camp  Smith  on  Oahu  in  February  19M  in 
an  intensive  study  of  procedures  currently 
employed  for  generating  and  distributing 
messages. 

The  required  funct  or.s  of  a  message 
service  identified  by  that  study  include 
facilities  to  old  in  message 

preparation,  transmission,  and  reception. 
Sophisticated  text  editors  can  make  it 
easier  to  prepare  the  various  initial 
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drafts  of  a  message.  Coordination  of  the 
message  (I.  e.,  getting  the  necessary 
approvals)  up  to  Its  final  release  can  be 
automated,  eliminating  the  present  need 
for  hand-carrying.  The  routing  of  a 
message  can  be  assisted  through  an 
automated  “directory  assistance"  service. 
Message  transmission  vl 1 1  be  virtually 
Immediate,  regardless  of  the  distance 
covered.  Many  aids  can  be  provided  the 
addressees  for  reading,  printing,  filing, 
and  retrieving  messages.  An  alerting 
mechanism  will  call  a  user's  attention  to 
the  arrival  of  a  hi gh-pr i or i t v  messaae. 
i  ac? 11  ties  for  scanning  messages, 
r eacif'.ressi  no  then  (sending  on  to  others 
'’rt  ^n  the  address  list),  and  informing 
the  nrioinator  of  action  taken  will  also 
prove  useful.  Other  requirements  l den- 
tified  were  various  facilities  for 
status  Inauiry,  programmi ng,  responsi¬ 
bility  tracing,  accounting,  training,  and 
interface  to  off-line  processes. 

Many  of  the  functions  Identified  are 
straightforward  and  already  exist  in 
present  systems.  Others  are  more  subtle, 
requiring  research  Into  methodologies  for 
their  1 mp I er entat i on.  As  a  part  of  the 
CONNECT  development,  the  existinq  pieces 
are  being  integrated  into  a  single  system 


to  which  are  being  added  the  necessary 
programs  to  conduct  the  research  reatil  red. 

An  experimental  message  service 
within  an  actual  military  user  community 
would  provide  an  excellent  basis  for 
conducting  some  of  the  needed  research  on 
the  application  program.  In  addition.  If 
the  user  community  were  carefully 
selected,  it  would  provide  the  opportunity 
of  performing  some  direct  technology 
transfer  without  the  usual  intervening 
development  cycles.  Investigation  of 
potential  sites  for  such  a  test  Is 
currently  under  way. 

SEC UR I  1  Y 

System  security  must  be  considered  at 
several  levels.  One  aspect  is  simply 
control  of  access  to  the  computer,  files, 
communications  links,  and  terminals.  A 
second  is  radiation  security  (i.e.,  the 
shielding  of  electromagnetic  and  acoustic 
emission  from  the  active  elements  of  the 
system).  A  third  Is  "privacy"  or 
operating  system  security,  so  that  one 
user  cannot  accidentally  or  intentionally 
have  access  to  files  to  which  he  Is  not 
authcri7ed.  This  last  consideration 
extends  also  to  reliability  In  that  one 
user  should  not  be  able  to  render  part  or 
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1 1  of  the  system  useless  by  any  operation 
he  can  perform  at  a  terml ns. .  Nor  should 
any  loan  condition  render  the  system 
Ineffective  to  critical  users. 

With  a  terml nal-c'iented  service  such 
as  that  proposed  for  COTCO,  security  can 
be  violated  through  a  large  number  of 
devices  (l.e.,  all  terminals  and 
communications  lines).  ihls  fact 

necessitates  either  stringent  access 
control  or  a  multilevel  plan  of  system 
security.  If  a  system  can  be  developed 
that  cannot  be  broken.  It  can  be  used  for 
both  unclassified  and  classified  messages: 
communications  lines  and  terminals  that  do 
not  carry  classified  traffic  will  not  need 
special  security  measures.  Otherwise,  all 
users  must  be  cleared  to  the  highest 
security  level,  and  all  communications 
lines  and  terminals  must  be  provided  the 
same  level  of  security  control.  Clearly, 
a  multilevel  secure  system  Is  an  Important 
Ingredient  to  realizing  the  full  potential 
of  message  technology  In  the  military 
communl t y. 

Even  In  a  multilevel  secure  system, 
those  terminals  that  handle  secure  traffic 
will  need  to  meet  the  access  and  radiation 
restrictions.  Radiation  control  of  CRT 
terminals  generally  requires  expensive 


filtering  and  shielding.  Display 

technologies  that  do  not  require 
refreshing  In  a  fixed  time  pattern  are 
much  less  prone  to  deciphering.  For  this 
reason,  plasma  and  other  direct-view 
i mage-storage  displays  are  being 

Investigated  as  potential  "secure" 
terml nal s. 

Communication  lines  between  terminals 
and  TIPs  and  between  TIPs  and  TIPs  must 
also  be  protected  from  being  read  by 
unauthorized  persons,  which  can  be  done  by 
specialized  "hardened"  wires  for  short 
runs  through  moderately  controlled 
environments.  Otherwise,  encrypting 

devices  can  oe  used  that  scramble 
the  data  on  the  line  so  It  Is 
unintelligible  except  to  a  matching 
decryptor.  This  encryption/decryption 
equipment  currently  tends  to  be  rather 
expensive  ($10,000  to  $15,000  apiece). 
Since  the  number  of  lines  between  TIPs  Is 
relatively  small,  encrypting  these  Is 
reasonable;  however,  encryption  at  the 
terminal  level  appears  extremely  costly. 
One  approach  to  sol'  ,g  this  problem  Is  to 
Install  local  multiplexors  to  reduce  the 
number  of  encrypted  lines.  for 
environments  In  which  this  Is  difficult, 
new  technology  must  be  applied  to  develop 
less  expensive  encryption  devices. 
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Encrypting  between  TIPs  on  the 

network  will  serve  no  purpose  unless  the 
TIPs  themselves  are  also  secure — which 
current  TIPs  are  not.  Designing  a 
certlflably  secure  TIP  Is  a  challenging 
but  achievable  feat  (Autodin,  for 

Instance,  Is  considered  secure).  It 

involves  security  clearances  for 
programmers,  careful  design,  classified 
program  listings,  and  complete  analysis 
and  testing. 

An  alternative  approach  to  TIP 

security  Is  to  develop  software  that  can 
be  proved  to  be  recure  (see  Section  2  of 
this  report).  To  date  r.o  such  system  is 
known  to  exist,  but  several  programs  are 
under  way  (at  Mitre  Corporation  and  UCLA, 
for  example)  to  develop  secure  operating 
systems  for  minicomputers. 

Another  alternative  Is  to  encrypt 
secure  traffic  at  the  terminal  and  the 
message  processor  only  and  have  the 

network  operate  In  the  clear  on  the 
encrypted  traffic  (I.e.,  all  the  network 
header  data  will  be  In  the  clear  while  the 
body  Is  encrypted).  This  Is  somewhat 
awkward  operationally  and  requires  changes 
to  the  ARPA  TIP  software  that  currently 
does  Interpretive  functions  on  the  data. 
It  also  opens  the  Information  about  the 


flow  of  traffic  within  the  network  to 
possible  penetration.  For  many  military 
purposes,  this  too  is  classified 
I nformatl on. 

The  Message  Processor  also  must  meet 
rigid  security  specifications.  Because 
there  are  relatively  few  Message 
Processors  In  the  system,  the  problem  of 
physical  access  and  radiation  security  Is 
manageable.  However,  development  of  an 
operating  system  that  provides  multilevel 
security  with  the  complexity  required  for 
message  processing  Is  another  major 
project.  If  the  system  s  closed  (not 
connected  to  other  systems)  and  Is  limited 
to  transactions  only  (no  programming 
a  lit  wed)  It  appears  to  be  feaslt  e. 
Security  of  full  general-purpose  operating 
systems  will  probably  have  to  await  a 
breakthrough  in  the  development  of 
mathematically  provable  secure  systems. 

RELIABILITY 

The  current  reliability  of  the  network 
and  host  computers,  although  possibly 
adequate  for  research,  will  not  satisfy 
the  requirements  of  an  operational 
ml  1 1 tary  message  system.  Unfortunately, 
the  various  factors  underlying  the 
reliability  of  such  a  complex  system  as 


RELIABILITY 


the  ARPANET  are  Imperfectly  understood.  A 
program  Is  being  outlined  to  determine  h<  »w 
to  collect  the  data  necessary  to  better 
understand  these  factors,  which  w! II  help 
In  formulating  specific  action  to  Improve 
network  reliability. 

It  Is  Imperative  to  produce  not  on  I 
a  program  to  reduce  the  probability  < 
component  failure  In  the  system,  but  c’.ao 
a  means  to  recover  from  failures  smoothly 
and  rapidly.  If  a  terminal,  encryptor, 
comrik  ''l  cat  I  ons  line,  or  TIP  In  a  system 
such  as  COTCG  falls,  the  Message  Processor 
will  retain  the  state  of  the  user  so  that 
he  can  recover  it  later  on  a  different 
channel.  If  a  Message  Processor  falls, 
the  total  system  must,  recognize  this  fact 
and  switch  his  connection  to  d  backup 
Message  Processor.  In  order  to  preserve 
the  files  In  this  case,  every  file  written 
by  p  essage  Processor  wi  1 1  be  sent  to  a 
backup  Message  Processor  as  well.  When  a 
Message  Processor  falls  and  a  user's  Job 
Is  switched  over  to  a  back-up  Processor, 
It  Is  Important  to  maintain  as  much 


apparent  continuity  as  possible  to  the 
user.  This  Implies  a  process  residing 
outside  the  user's  primary  Message 
Processor  that  Is  monitoring  the  status 
and  context  of  the  user's  activity.  This 
process  then  controls  the  switchover  and 
keeps  the  user  Informed  of  events  as  they 
ppen.  These  recovery  functions,  wnlch 
c  not  currently  Implemented  In  the 
network,  must  be  completed  before  a 
reliable  system  can  be  provided. 

CONCLUSION 

The  CCMPT  project  Is  currently  In  a 
study  phase,  identifying  the  problems  and 
the  opportunities  for  message  processing 
systems  In  the  military  environment.  A 


program 

out  1  i 

i  ni  ng 

detai led  areas 

for 

research 

is 

now 

being  prepared. 

1  n 

addition,  we  are  exploring  opportunities 
for  Joint  development  with  military  users 
that  will  apply  our  message  technology  In 
experimental  form  to  actual  military 
si tuatlons. 
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INTRODUCTION 


Many  large  s 

egments  of 

the 

mi  1 1  tar y 

(most  critically 

,  perhaps. 

Command  and 

Control)  depend 

as  heavl 1 y 

on  the 

tr ansrni ssl on  of 

i  nformat i on 

as 

on  the 

tr anspor t at i on  of 

people  and 

materiel.  At 

present,  sending  and  responding  to  a 
typical  military  message  (using  a  variety 
of  manual  and  semi automati c  techniques) 
requires,  at  best,  days.  Using  an 
automated  computer-based  sender/recel ver 
on-line  message  service  system,  the  same 
communication  could  be  completed  within 
mi nuter . 

The  technology  exists  today  to 
produce  systems  for  automatic  communi¬ 
cation.  Wr at  does  not  exist  Is  a 
methodology  for  making  such  systems 


e  f feet  1 ve  and  attract i ve  for  people 
unfamiliar  with  the  use  of  computers.  The 
Information  Automation  ( IA)  project  at  ISI 
is  design! nq  and  developing  this  kind  of 
fully  automated  easy-to-use  interactive 
communl cat i on  system  to  improve  the 
e f feet i veness  of  action  officers'  message 
generation  and  sending  capability.  The 
proposed  system,  called  Communl cati ons 
Network  Nodes  Effected  ry  Computer 
Terminals  (CONNECT),  is  designed  to  serve 
a  large  class  of  both  technical  and 
nontechnical  users  (including  clerical 
personnel  and  managers)  and  could  be  used 
tc  aid  many  everyday  military  base 
communl cat i ons  activities  as  well. 

CONNECT  could  also  be  useful  to 
or qanl zat i ons  with  geographl ca I  I y  distant 
offices  needing  to  maintain  constant 
communication  with  each  other.  Because 
CONNECT  will  be  designed  to  serve  a 


Preceding  page  blank 
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variety  of  users 

vith  a 

v  ar  i  et  y 

o  f 

communications  r equ i r eir.e  its,  i 

t  shou 1 u 

be 

able  *o  meet.  many 

civi  i 

as  veil 

as 

mi  1 1  tar  y  neeas  . 

Fu  nc  t »  era  1  E>peci  f icatiors 

The  functions  required  of  a  message 
service  like  CONNECT  can  De  divided  Into 
five  classes^  message  preparation,  message 
trans  mi  ss  I  cr  .  '•’vssage  reception,  infor¬ 
mation  i,.  ?i  n  ten  once ,  and  off-line 

func  liens.  (The  word  "message"  loosely 
refers  to  any  formal  or  informal  witter 
document.)  In  addition  tr  the  message- 
related  functions,  the  on-line 

capabilities  Include  access  to  compu¬ 
tational  facilities,  since  users  of 
CGNNTCT  may  communicate  vith  computat i ona I 
processors  linked  to  the  conmuni cat  ions 
oetvork. 

Message  p" epar  at i on.  Message 

preparation  basically  consists  of 
composing  text  and  obtaining  approval  for 
sene..- r.g  it.  The  user  corresponds  %i  cn  a 
message  creation  function  by  means  of  a 
simple  dialogue.  CONl  .  CT  is  de'igned  to 
handle  .‘6n.‘-«rd  formats  and  can  prompt 
users  for  necessary  completions.  When 
several  people  are  Involved  in  message 
preparation,  the  hand-carry  phase  of 


toor dl nat 1 ng  toe  message  for  app/oval  Is 
automated. 

Message  tr ansml ss 1  on.  The  message 
transmission  function  provides  facilities 
to  verify  destinations  and  to  moni tor  the 
message's  status.  The  service  validates 
the  addresses  of  the  list  of  recipients 
provided  oy  the  originator  of  the  message. 
If  the  recipient  is  not  currently 
accessible,  CONNECT  can  deliver  the 
ness a go  tc  a  responsible  alternate,  or 
maintain  the  message  until  the  recipient 
available.  CONNECT  users  can  ascertain 
the  status  of  a  message  ry  Cleans  of  such 
queries  as  ’Has  it  been  read?"  and  "By 
vnom?*,  or  "is  action  pending?",  and  "By 
vno».i?"  (query  rights  cf  addressees  can  be 
limited  by  Che  messaqe  o- i qi natc r . ) 

Message  recept  lor..  while  several 
modern  systems  provide  adequate  message 
transmission  facilities,  few  give  in-depth 
consideration  to  the  rec»i/er's  needs, 
some  of  vnich  are  tne  foilovingl 

■  The  service  should  provide  some  audible 

and/or  visual  alarm  to  a*ert  a 

receiver  to  a  ne»  pending  message. 

■  Messages  should  be  ordered  to  reflect 

priority,  originator,  subject,  etc.. 
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Mklng  It  easier  for  the  user  to 
scan  messages 

Browsing  should  be  available,  either 
for  reading  large  messages  or  for 
f  ami  1 1  ari  zl  ng  new  personnel  with  a 
particular  correspondence  file.  Aids 
for  Increasing  efflc  /  In  scanning 
large  numbers  of  messages  (e.  g.  , 
key  vord  -earches)  should  be 
prov I ded. 

Users  should  be  able  to  forward  or  copy 
messages  to  others,  although  In 
special  situations  tr»*  sender  may 
limit  this  capability. 


Reel  pi ent  s 

should  be 

abi  e 

to 

automat  1  cal 

•  y 

generate 

f eedback 

to 

senders,  suen 

as  "Message 

not  read 

M 

* 

"Read  but 

no 

action," 

and  "Action 

pend?  ng. * 

Messages  should  be  received  in  a  form 
that  allows  them  *o  be  incorporated 
into  other  documents, 

l n for  mat i on  mai ntenance.  Information 
structures  such  as  archives, 

correspondence  files,  name  and  aedress 
files,  and  schedule  files  are  maintained. 
All  Information  Is  auto>  tlcally  archived 
to  provide  a  reliable  repository  for 
messages.  Users  may  create  specific 


correspondence  files  for  all  messages 
pertaining  to  a  particular  subject.  Other 
users  may  subsequently  address  messages  to 
an  addressee's  particular  correspondence 
file  rather  than  to  his  general  delivery 
f 1 Jes. 

Of  f- 1 1  ne  funct I ons.  CONNECT  supports 
the  generation  of  documents  such  as 
reports  and  letters  destined  for  off-line 
distribution.  Functions  available  will 
include  report  preparation,  editing,  and 
formatt i ng. 

EXISTING  TECHNOLOGY 

Hardware 

The  CONNECT  service  operates  within 
existing  network  and  time-sharing  tech¬ 
nology.  Its  components  are  (1)  the 
ARPANET,  (?)  tne  TENEX  1 1  me-shar  1  ng  oper¬ 
ating  syste.fl,  (3)  the  Xerox  Graphics 
Printer  (XuP),  and  (A)  hi gh-bandwi dth/ 
soft-copy  minals,  Some  of  the  com¬ 
ponents  /f  CONNECT  are  unique,  whi  ie 
•jtners  have  functional  equivalents 
throughout  the  industry.  M*ost  were  chosen 
because  of  their  acce ss I bl  1 1 ty  to  the 
project. 

1)  The  AkPANET's  unique  concatenat i on  of 
computer  resources  provides  redundant 
communi cat  I ons  paths  for  reliable 
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connect i ons 

to  remote 

poi nts , 

and 

its 

modu 1 ar I ty 

a  1  1 ows  the 

total 

system 

to 

expand  or 

cont  r act 

1 ncremental 1 y 

as 

r  equi red. 

2)  Each  host  computer  on  the  AftPANf T 
that  vi I i  he  providing  a  message  service 
vi ) I  be  a  digital  Equipment  Corporation 
t'ut- 10  using  the  7ENEX  operating  system. 
CONNECT  vi 1)  shield  the  user  from  the 
varied  system  load  levels  to  produce 
uniform  response  time.  In  a  later  test 
environment  the  user  viil  communicate 
directly  with  CONNECT,  omitting  the 
dialogue  with  the  TtNEX  ixecutive. 

j)  Ire  XG  t\  d  high -quality  raster 
printer  connected  to  a  support  computer, 
provide  tte  necessary  haro-copy  facility 
tc  disseminate  messages  and  report, 
outside  r  he  service.  >. ' j  r  car.  do  used  as  a 
typewriter  replacement  to  maintain 


nacni ne 

-r eaoab 1 e 

copi  es 

of  all  cut  go! nq 

cor  resp 

omifnce. 

v)  uf 

tn»*  many 

s u i table 

t  »  r  mi  na  1  s  ,  twe 

par  t  i  ct 

;  r  t  n  i 

ri d  1  s  are 

neinq  considered 

y  tne 

i  A  project 

S  t  a  f  f  i 

t  no  I  nsl  1  <.  ut  o 

I  *  r  mi  na 

1  system 

(  i  oj  .in 

d  tr.i  i  7  r  L  u .  i  i  s 

i  .  «j  oc 

un  i  e  -o#*rd,  1 

t  y  i  V  -  h  i 

sed  ,  ystem  rein.. 

uL1 «  «  t 

/  or  I  „  i 

by 

systems  Ccncepts 

Ir.c  .  Terminals  display  \*  lire-  r>t  ,..J 
(  h.trd  r  er  -ut  ;  t :  »  i  i.-iv*  v«ir  i  an  1  * 


control  of  character  fonts  and  Xerox 
urapnlcs  Printer  compatibility.  Ihe  TTY40 
is  a  new  sof t -copy/nar d-copy  terminal  to 
oe  offered  py  Teletype  Corporation, 


purported  to  dp  of 

par t i cu 1 ar 

i nterest 

wnere 

secur I t  y  Is 

par  amount 

• 

A  large 

number 

of  me d I  u m 

-bandwi dt  h 

soft -copy 

t  e  r  m  i  n  a 

Is  are  avai 

lable  on  the 

mar kut  i n 

the  $ 2 , 

000  to  > ,000 

range.  7 

he 

above  two 

are  of 

par  t  i  cu  1  er 

I  ntp-  r  est 

i  n 

that  the 

first 

is  already 

aval lable 

and  hjy 

f  ler* 

wr  .a  the 

seconc 

i  S 

expected 

to 

aval  1 ab I e  for 

c 

i  ass i f i ed 

app  1  i  cat .  _  .s  . 

User  Inter  f ace  7 <  c r n ?  cues 

It  is  an  important  part  of  the 
LuNNECT  pt'i  losopny  to  treat  each  user  as 
an  individual.  Amonq  the  techniques 
previously  used  to  smooth  the  user 
Interface,  CONNECT  emphasizes  the 
following!  f  or-nrack  responses,  homo¬ 
geneity,  help  features,  error  handlers, 
did  individualized,  i  nt  »-r  faces. 

feed  LoC  r  r  es,, crises  .  in  its  simplest 
lorn,  the  response  merely  tells  the  user 
that  C.jNNsCI  I  operational  and  ^nder- 
stnnos  his  request.  However,  many  of  the 
!  «■*  ,  *ck  r^sp*  n,f$  also  prompt  tr-e  user 

f<-.'  input.  ihrse  snort  passage  gotten 
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one  character)  change  as  the  user  roves 
from  state  to  state;  they  might  differ 
when  the  user  is  typing  commands,  as 
opposed  to  entering  text.  Other  kinds  of 
feedback  respon.es  are  messages  that 
describe  the  service's  last  action;  some 
are  more  elaborate  prompts  that  give  more 
detai led  instructions  describing  the 
expected  input.  Other  responses  are 
associated  with  abbr evi at i on:  or  short 
forms  of  commands.  These  include  vays  for 
the  user  to  request  the  expansion  of  an 
abbreviation  in  order  to  confirm  the 
service's  rt  ognition  of  I  is  intentions. 

Homo gene i t y.  7  c  insure  natural  use, 
actions  common  to  services  are  carried  out 
in  a  consistent  way.  jf  the  user  knows 
now  to  do  something  in  one  context  (supply 
a  date,  specify  someone's  name,  refer  to  a 
fiie,  etc.)  he  can  do  it  th'  same  way  i  r, 
any  other  context,  wnJch  increases  user 
confidence  and  reduces  errors  and  learning 
time.  This  is  not  to  say  that  parameters 
tnat  are  not  meaningful  in  some  context 
are  required  just  for  consistency,  nor 
that  the  usual  construction  o.'  a  request 
must  specify  enough  information  to  resolve 
the  most  amoi guous  context.  In  the  former 
case  s I mp 1 1 f i cat i on  is  accepted;  in  the 
latter  case  ambiouous  requests  result  In 
further  interaction  to  clarify  the  user's 


intent.  Homogeneity  does  not  Interfere 
with  natural  operation.  Recognition  of 
abbreviat Jons,  for  example,  may  be  highly 
context-dependent  (e.g.,  recognition  of 
file  names  is  limited  to  the  user's 
current  set  of  files).  7o  enforce 
consistency  would  require  prohibiting  suc.i 
recognition.  Rather,  CONNECT  provides 
consistent  ways  of  asking  for  further 
spec  I f I  cat i on  when  necessary. 

He  1 p  f eatur es.  Help  features  aid  the 
user  in  detarmining  his  choice  of  actions 
at  any  given  time  and  the  consequences  of 
these  actions.  They  are  of  two  varieties- 
onp  Initiated  by  the  user,  the  other  by 
the  service.  User - 1 ni t i ated  help  features 
include  reauests  such  as  the  local  time  at 
a  message  destination,  the  status  of  an 
operation,  or  a  tutorial  on  some  service. 
CuNMECT-generated  help  features  a.  e 
triggered  by  user  actions.  For  example, 
i  f  the  user  attempts  to  use  a  command  h 
has  never  used  before,  the  service  may 
recommend  a  short  tutorial  on  the  use  of 
the  command.  If  the  user  is  making 
repetitive  errors,  assistance  Is  offered, 
perhaps  in  the  form  of  an  explanation  of 
the  service's  current  expectation  from  the 
user  or  a  more  detai  led  tutorial  dialogue 
with  him.  Also,  If  the  user  Is  doing 
something  awkwardly,  CONNECT  can  teach  him 
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a  new  command  to  alleviate  the  difficulty* 
In  this  case  the  motivation  for  the  new 
command  will  be  clear  to  the  user.  For 
examr!-*,  CONNECT  may  suggest  a  composite 
command  to  replace  a  frequently  repeated 
command  sequence. 

Error  hand 1 er s .  The  proper  response 
to  errors  is  of  major  importance  in  a 
we  1 1 -desi gned  user  interface  to  an  cn-Iine 
service.  CONNtCT  is  concerned  with 
detection,  prevention,  correction,  and 
notification  of  any  detected  errors.  When 


an  error 

is 

detected. 

the 

cause  Is 

explai ned 

to 

the  user 

in  detai  1  ,  and  he 

day  then 

be  invited  to  use  the 

tutor i ai . 

Terse  or 

cooed 

messages 

are  avoided.  When 

an  error 

i  s 

detected. 

the 

offend] ng 

command 

is 

aborted. 

When 

the  user 

di  .^covers 

a 

semant i c 

error , 

he  has 

convenient  ways  to  remedy  its  effect  by 
specific  commands  that  undo  the  effects  of 
previous  commands.  In  concert  with  error 
correction,  he  has  powerful  i  nt r acommand 
edi  ti  ng  Matures. 

Indi vi dual i zed  Inter  f aces.  CONNECT 
permits  ^ser:  to  select  personal  desig¬ 
nations  for  commands  and  even  create  macro 
commands  for  ttemselves  to  simplify  or 
expedite  their  work.  On  the  basis  of  a 
profi le  maintained  for  each  user,  CONNECT 


adjusts  Its  internal  operating  parameters 
to  fit  his  individual  style,  tailoring  its 
prompting  and  feedback  responses  to 
reflect  his  familiarity  with  the  service. 

RESEARCH  DIRECTIONS 

In  addition  to  technology  already 
available  for  Implementing  CONNECT,  some 
innovative  methods  are  needed  to  deal  with 
the  problems  'ac.ng  the  nontechnical  user. 
These  metnods  fa  1 1  into  four  categories* 

•  Adaptive  processes 

■  Program  structures 

■  Integrated  tutorials 

«  Response-time  adjustments 

Adapt i ve  Processes 

A  common  fault  of  many  man-machine 
systems  is  that,  although  they  provide  the 
necessary  functions,  they  fall  to  fit  any 
particular  application  very  well.  This 
prop  em  may  be  due  to  a  riiid  command 
structure  that  requires  using  overly 
complex  commands  to  perform  often-used 
functions.  CONNECT,  on  the  other  hand,  is 
much  more  adaptable  to  each  of  its 
potential  appl Jcatlons.  The  wide  range  of 
message- like  functions  It  supports  were 
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determined  by  studying  potential  (seml- 
automated  and  manual)  user  environments. 
The  user  Interface  Is  incompletely 
specified  except  with  re< pect  to  a  par¬ 
ticular  group  of  Indlvldjals.  The 
command  language  and  service  Idiosyn¬ 
crasies  are  adjusted  *on  site*  to  suit 
the  Individual  «.ser  environment.  The 
■on-site*  adjustments  are  aided  by  models 
of  users  and  services  that  are  used  as 
predictors  In  choosing. 

In  addition  to  this  site-dependent 
preadjustment,  the  service/user  Inter¬ 
actions  and  Intraservice  dependencies  are 
Instrumented.  Data  samples,  collected 
through  real-time  measurements,  are 
analyzed  on  the  spot,  and  Immediate 
adjustments  are  recommended  to  the  user. 
The  purpose  of  such  dynamic  evaluation  is 
to  further  refine  the  user's  performance. 
While  techniques  for  service  self- 
regulation  are  perhaps  the  least  veil 
known  and  understood  of  the  various 
techniques  discussed  below,  the  potential 
increase  In  efficiency  to  be  cained  by  the 
use  of  Instrumentation  and  adaptation  Is 
thought  to  be  great  enough  to  warrant 
including  this  aspect  In  the  project 


Program  Structure 

Most  large  programs! ng  systems  are 
structured  to  minimize  the  Interactions 
between  modules,  which  provides  clean 
Intermodule  Interfaces  (In  many  cases  null 
Interfaces).  This  approach  also  tends  to 
produce  vertical  part  1 1 lonl ng,  in  which 
each  module  decides  and  provides  for 
Itself  In  all  situations,  resulting  in  an 
uneven,  heterogeneous  system.  CONNECT  Is 
partitioned  her  I zonta I ly ,  with  each  module 
responsible  for  a  single  service-wide 
function;  all  other  modules  needing  this 
function  use  the  single  module  designate^ 
for  that  purpose. 

Horizontal  structure  prevents  several 
classical  human -re I ated  problems.  Firs*-, 
nc  application  module  Interacts  directly 
with  the  user,  A I i  input  or  output 
activities  are  handled  by  a  collection  of 
Interaction  modules,  which  In  turn  I nsures 
that  ;ach  Implement er  will  give  more 
thought  to  the  user  Interface  standards. 
Second,  each  module  (several  may  be  active 
simultaneously)  maintains  state  I nf or- 
mation  In  a  data  table,  which  allows 
CONNECT  to  know  Its  total  state,  a 
requisite  for  service  monitoring  of  user 
interaction.  Finally,  all  modules  must 
Indicate  on  return  how  to  reverse  their 
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effects,  which  gives  the  user  methods  to 
abort  or  undo  previous  actions. 

Integrated  Tutorl als 

Today  many  examples  can  be  found  of 
either  computer-ai ded  instruction  (CAI)  or 
computer  systems  with  help  features. 
CONNECT  Integrates  the  two  Into  a  tutorial 
service  with  novel  capabl I i t I es.  When  the 
user  requests  help,  he  Is  automati ca I  I y 
connected  to  the  tutorial  module.  Aside 
from  conducting  fixed  dialogues  with  the 
user,  the  tutorials  are  able  to 
demonstrate  commands  to  the  user,  ana  can 
also  ask  the  ser  to  try  things  and 
observe  any  problems.  In  fact,  a  novice 
user  mi gnt  spend  his  first  sessions 
totally  under  tutor  observation. 

In  addition  to  the  above1  method  of 
operation,  the  tutorial  service  aids  the 
us  'in  personalizing  language  constructs 
to  reduce  or  eliminate  those  forms  that 
lead  to  Inefficient  and  ineffective 
per  for mance. 

Fes  pot  j  e - 1 i me  Adjustments 

Most  interactive  application  systems 
attempt  to  minimize  response  time. 
However,  we  oelieve  that  response-time 
char actcr i st i cs  should  oe  a  stated. 


realizable  goal,  not  an  I nstantaneous , 
unrealizable  ideal  only  erratically 
approached.  CONNECT  does  not  try  to 
minimize  response  time;  Instead,  It 
adjusts  response  time  in  concert  with  the 
user's  psychological  expectations.  Con¬ 
siderations  include  the  following- 

■  Providing  constant  response  for  a  given 

action,  so  that  the  user  knows  what 
to  expect. 

■  Making  smaP  resna^se-t i me  adjustments 

to  decrease  tne  user's  error  rate. 

■  Allowing  the  user  to  do  other  work 

while  waiting.  If  a  request  Is  not  an 
interactive  response-time  task. 

EVOLVING  DESIGN 

The  design  of  the  CONNECT  system  has 
evolved  to  meet  tne  needs  and  problems  of 
prospective  users.  I  he  design  now 
consists  of  two  parts!  the  core  system  and 
a  set  of  application  modules.  While  the 
application  modules  have  not  been 
specified  in  much  detai I  to  this  point, 
the  core  system  fas  been  designed  to  a 
fair  I  eve  I  of  detail. 

This  core  system  consists  of  five 
parts!  I)  an  Executive  that  supervises  the 
execution  of  the  system  and  provides  the 
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interface  between  the  operating  system  and 
the  rest  of  the  service  (I.e4,  the  rest  of 
the  core  and  the  application  modules); 
2)  a  Command  Language  Processor  that 
parses  and  examines  all  Input  to  the 
service  and  maintains  a  consistent 
interface  between  the  user  and  the 
application  modules;  3)  an  EdI tor  respon¬ 
sible  for  all  text  manipulations  the  user 
may  require;  4)  an  Instrumentation  and 
adaptation  package,  called  the  User 
Monitor,  that  monitors  the  user's 
interactions  and  suggests  new  dialogue 
elements  to  personalize  the  interface  for 
eacn  user;  and  finally,  S)  a  Tutor  that 
teaches  the  user  and  aids  him  in 
regulating  the  dialogue  forms  for  maximum 
user's  performance. 

Ine  Execut i ve 

The  CONNECT  Executive  (Exec), 
functioning  as  the  interface  between  the 
operating  system  and  the  remal nder  of  the 
CONNECT  system,  serves  the  following 
purposes  • 

1)  It  buffers  the  terminal  u.ar  from 
interaction  with  the  primary  operating 
system  and  channels  all  error  Interaction 
and  housekeeping  communication  through  the 
appropriate  CONNECT  module. 


2)  It  acts  as  a  common  channel  through 
which  all  modules  request  service  from  the 
operating  system,  in  order  to  buffer  the 
rest  of  the  system  from  changes  to  or 
replacement  of  the  primary  operating 
system. 


3)  It  provides  the  primary  operating 
system  two  supp lementar y  services* 
fulfillment  of  requirements  not  satisfied 
Dy  TENEX  and  refcrmu lati on  of  TENEX 
service  in  a  form  suited  to  the  CONNECT 
system  or  to  particular  CONNECT  fu  ctions. 


Executive  services  provided  Include 
error  control  and  system  request  routing. 
The  Exec  supplements  TENEX  services  both 
by  providing  services  not  available 
through  TENEX  and  by  reformu l ati  ng  certain 
TENEX  services  for  the  convenience  of  the 
programmer . 

T he  Command  Language  Processor 

The  Command  Language  Processor  (CLP), 
which  processes  all  user  inputs,  is  the 
complete  logical  input  interface  between 
the  user  and  the  rest  of  the  system  (and 
may  be  the  complete  output  Interface  as 
*eli).  The  CLP  rust  satisfy  fojr 
sometimes  conflicting  requ I r ements * 


73 


EVOLVING  DESIGN 


1)  because  the  CLP  provides  the  language 
and  mechanism  for  service  modules  to 
communicate  with  users.  It  must  be  general 
and  flexible.  It  must  provide  a  command 
language  definition  capability  powerful 
enough  for  the  interactive  service  modules 
not  as  yet  specified?  at  the  same  time, 
however,  it  must  be  simple  and  convenient 
enough  to  use  so  that  the  service  module 
authors  are  willing  and  able  to  use  it. 

2)  It  must,  at  the  same  time,  establish 
an  interface  that  can  be  understood  by 
comput  er -nai  ve  users  -0  th  minimal 
training.  Its  commands  must  be  simple  and 
consistent.  While  providing  a  language 
for  writing  commands  for  service  module 
authors,  the  CLP  must  simultaneously 
represent  the  needs  and  interests  of  the 
intended  users.  Experience  with  other 
computer  systems  has  shown  that  these  two 
requ  I  restents  are  often  in  direct  conflict. 


3)  CIP 

must  provide  alternate 

ways  for 

users  to  express  their  need 

s  • 

A1  ternate 

forms  are  used  when  the 

User 

Moni tor 

detects 

i ne  f f J  c J  ent  or 

i ne  f  f ect i ve 

dl  loque 

and,  vi a  the  Tutor  , 

suggests  an 

I mproved 

form  for  a  particular 

user.  If 

the  user 

elects  to  employ  a 

new 

d  I  a  1  o  gu  e 

e | e  merit , 

the  CLP  must  be  able 

to 

parse  and 

under  stand  i t . 


4)  finally,  CLP  must  perform  all  Its 
functions  J  rt  an  especially  transparent 
manner.  It  is  expected  to  make  available 
to  the  Tutorial  and  Help  subsystems 
information  about  existing  commands,  the 
user's  knowledge  and  use  of  them,  and  a 
recent  history  preced.ng  an  error. 

The  CLP  may  be  seen  as  t  discrete 
( hor i 2onta i I y  structured)  pieces^  (1) 
the  Parser,  String  Processor,  or  Compiler 

(2)  the  Interpreter,  Virtual  Machine, 
or  Executor,  In  effect  the  CLP  Is  both  a 
complier  (  ror  the  command  language  a '» 
entered  by  the  user)  and  the  virtual 
machine  whose  "machine  language"  Is  the 
target  language  into  which  the  compiler 
translates  the  user  language.  Within  this 
viewpoint  the  remainder  of  the  system 
provides  the  functions  that  help  define 
the  virtual  machine.  Henceforth  we  refer 
to  the  first  part  of  the  CLP  as  tne 
Command  Language  Compiler  (CLC)  and  the 
second  part  as  the  Command  Langu 
Executor  (CLE). 

Command  Language  Gompl ier.  The  task 
of  CLC  Is  to  take  the  corrected  input 
store  and  produce  a  program  executable  by 
the  CLE.  CLC  has  as  two  of  Its  goals  to 
provide  a  consistent,  system-wide  flavor 
to  the  conur.jnd  language.  In  order  to 
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achieve  these  goals,  CLC  takes  a 
pseudo-natural -language  approach  to 
commands,  with  the  command  language 
defined  In  terms  of  a  very  simple 

''ngli  sh-I  I ke  syntax.  This  is  not  to  say 

that  CLC  attempts  to  interpret  anything 
like  general  English  Input.  Rather  the 
CLC  command  syntax  uses  the  same  basic 
notations  and  categories  (noun,  verb, 
adjective,  etc.)  that  native  English 

speakers  comprenend.  Ail  rules  provided 

by  each  application  module  are  defined  in 
these  terms i  the  application  module  author 
is  required  to  categorize  the  words  he 
uses  to  fit  this  framework.  CLC  uses 
this  framework  to  provide  horizontal 
consistency  throughout  the  command 
J  anguage. 

Command  Language  Executor.  CLE 's 
task  Is  to  perform  the  services  requested 
by  the  user,  which  It  accomplishes  by 
making  calls  on  other  modules  of  the 
overa 1  I  system. 

The  Edi tor 

The  design  of  the  CONNECT  Editor  has 
proceeded  from  three  basic  maxims* 

1)  Whenever  the  user  Is  typing,  he  is 
entering  text  and  should  have  available  to 


him  as  much  of  the  Editor  as  is 

appropr  1  ate. 

2)  There  should  be  as  little  dl f ference 
as  possible  between  the  text  as  the  user 
sees  it  while  editing  and  the  text  that 
would  appear  in  hard  copy  at  that  moment. 

3)  The  Edl tor  should  provide  ail  the 
basic  capabilities  of  paper,  pencil, 
scissors,  paste,  and  typewriter  while 
being  as  natural  to  use  as  possible. 

A  careful  examination  of  the  range  of 
possible  user  environments  also  produces 
some  boundaries  defining  what  the  CONNECT 
Editor  should  not  attempt  to  do.  In 
particular,  since  the  Editor  Is  not 
envisioned  as  a  "program*  editor,  it 
will  not  seek  to  provide  specific 
progr am-structure-or i ented  commands,  nor 
will  it  support  the  writing  of 
sophisticated  editing  programs  such  as 
might  be  required  if  Its  users  were 
primari'y  programmers.  It  will  also 
restrict  itself  to  nongraphic  editing.  In 
deference  to  the  limits  of  commonly 
available  and  Inexpensive  CRT  terminals. 

The  design  of  the  Editor  may  be 
viewed  at  three  logical  levels*  the 
correction  function,  low-level  editing, 
and  the  fu I  I  edi tor. 
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The  Corrector  provides  Intra<Ine 
editing  of  the  user's  Input,  whether 
commands  or  text.  This  must  be  carefully 
human -engi  neered  to  be  as  natural  as 
possible  (though  this  obviously  varies 
depending  on  terminals).  This  level  of 
the  Editor  requires  absolutely  minimal 
training  and  has  the  f 1 avor  of  actually 
"making  corrections"  rather  than  "issuing 
commands"  to  an  editor.  As  far  as 
possible  (dependent  on  the  terminal's 
local  capabilities  and  bandwidth 

cons J derat i ons )  the  results  of  tnese 
corrections  should  be  reflected  back  to 
the  user. 

Low-level  editing  is  accomplished  by 
simply  generalizing  the  Corrector's 
intraline  capabilities  to  exte.d  to  text 
in  general.  With  greater  "moving" 
capaoility,  the  user  can  perform  any 
editing  task  wi thout  needing  "linguistic" 
commands.  If  the  Corrector  Interface  Js 
natural,  this  low-level  editor  requires 
almost  no  additional  training.  It  does 
not,  of  course,  provide  the  power  of 
searches,  block  transfers,  or  replacing, 
out  it  does  allow  a  user  to  start  using 
the  system  to  edit  text  almost  as  soon  as 
hie  can  log  on.  This  level  also  includes 
t^xt  reading  facilities. 


Full  editor  capabilities  Include 
search,  replace,  restructuring,  block 
mani pu latJon,  Interfile,  mu  I tl -author,  and 
annotation.  They  attempt,  however,  to 
minimize  the  number  of  distinct  commands 
without  going  to  the  opposite  extreme  of 
complex  parameter i zat ion.  They  also 
attempt  to  optimize  tie  tradeoffs  between 
terseness  and  intelligibility,  and  between 
feedback  and  bandwidth  requ i rements. 

User  Mon 1 1 or 

The  main  purpose  of  today's 
har dware/sof twar e  measurement  tools  is  tc 


aid  in  the 

des i qn 

or  selec  ion  of 

new 

equi  pment 

or  the 

r  econ f i pu r  a t  i  on 

of 

present  equipment. 

One  criterion  or 

a 

cornoi  nation  of  criteria  is  established  as 
o  metric  (suen  as  processing  a  specified 
job  to  maximize  throughput  or  minimize 
cos*  ).  Our  interest,  however,  in  an 
instrumentation  and  adaptation  package  is 
to  Increase  the  user's  performance  (as 
oposed  to  tne  system's  performance)  as  he 
uses  a  service  of  a  time-sharing  system. 
Thus,  the  User  Monitor  Jnstrumems, 
evaluates,  and  predicts  user/system 
behavior  patter*.  in  order  to  regulate 
serv 1 ce  activities  and  the  user's 
practices  to  optimize  the  user's 
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per  for  mance .  The  following  I  I  lust.rate  the 
nature  of  Improvements  to  be  made  In  real 
t  i  me . 

1)  Detect  when  the  ue.  er  Is  dolnq  things 
•wrong*  by  means  of  elicited  errors  or 
repetitive  operations.  Here,  we  are  not 
looking  for  errors  tnat  prohibit  usefu* 
work,  but  rather  tnose  that  contribute  to 
poor  performance.  Corrective  action 
involves  interaction  witn  the  user, 

2)  Detect  when  the  user  has  mastered 
elementary  sequences  of  operations  and 
then  advance  tutoring  to  the  next  level  of 
language  constructs  useful  to  his  work. 

3)  Model  the  system  and  user  to 
determine  wnen  a  di fferent  sequence  of 
events  can  more  effectively  accomplish  the 
same  task. 

To  improve  performance,  adaptive 
features  must  be  able  to  affect  system 
operation  in  real  time  according  to  the 
fluctuations  in  system  and  user  actions. 
Hence,  measurement.  and  regulatory  aids 
must  be  designed  as  an  integral  cart  of 
the  system  in  order  to  assist  resource 


schedu  i  1 
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ly 
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possible.  Much  of  the  data  related  to 
per formance  cannot  be  accurately  estimated 
by  the  user,  since  large  I ne f f i c I  end es 
can  occur  in  small  time  frames  that  cannot 
be  detected.  Hence,  measurements  are 
integral  and  are  taken  in  real  time. 

To  succeed  in  real  time.  the  User 
Monitor  must  employ  a  data  extraction 
technique  that  does  not  s  i  grii  f  i  cant  I  y 
alter  the  system's  ope.ation.  Hence, 
pseu do-random  sampling  rather  than  event- 
oriented  monitoring  Is  used  primarily. 
Synchron i zat i on  Is  avoided  to  insure  that 
the  data  obtained  is  a  function  only 
of  the  number  of  samples,  not  the 
sampling  frequency. 

Operating  within  these  pr er equ i s i tes , 
tne  User  Monitor  .\as  two  very  di  fferent 
functions.  The  first  is  connected  with 
the  exoer i mentu i  goals  of  the  project.  As 
experiments  are  run,  the  User  Monitor 
makes  measurements  in  real  time  and  in 
background  analyzes  the  acquired  data. 
Inferences  based  on  the  results  are 
made  by  the  designeis.  Ihus  a  user's 
per formance  is  correlated  wJ tn  an  off-line 
model  of  the  user  and  the  service.  Given 
models  nf  the  user  and  service,  they  may 
be  used  in  c ne  future  as  predictors  for 
choosing  language  forms  yielding  best 
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performance,  best  teaching  methods,  and  so 
for th. 

The  second  function  is  to  aid  the 
user  (via  the  Tutor)  in  Improving  and 
personal  I z I ng  elements  of  the  language. 
Three  cases  arise.  The  first  case  Is  to 
recognize  dialogue  sequences  which  occur 
with  significant  regularity.  Once 
Identified,  the  Tutor  will  suggest  a 
composite  form  to  the  user.  The  second 
case  arises  where  the  CLP  Is  unable  to 
recognize  an  lr;ut.  The  Monitor  attempts 
to  Identify  the  spurious  command  and 


suggest 

(via 

the 

lutor ) 

°  remedial 

acti on . 

The 

thi  rd 

case 

.  olves  the 

1  so  1  at  I  on 

of 

those 

1  anguage 

constructs 

that  do  not  prohi b! t  useful  work  but  do 
lead  to  poor  performance.  Again, 
alternate  forms  are  recr  Tmended  through 
the  Tutor. 

The  Tutor 

One  of  the  prime  alms  of  CONNECT  Is 
to  be  easy  to  learn  and  forgiving  to  use. 
A  crucial  aspect  of  both  these  goals  Is 
the  provision  of  fully  integrated  help  and 
teachl ng  f acl 1 1 1 1 es . 

A  number  of  systems  make  use  of  a 
or  ■Help"  feature  to  allow  the  user  to  esk 
for  assistance  whenever  he  Is  confused. 


Typically,  these  use  a  minimal  amount  of 
the  user's  recent  actions  to  make  a  guess 
at  what  the  user  wants  to  know,  then 

provide  him  with  a  short  description  or 
list  of  options  open  to  him  at  this  point. 
A  slightly  more  sophisticated  approach  Is 
to  give  the  user  a  set  o*  choices  and 

converse  with  nl m  tc  find  out  what  he 
wants  to  know,  although  this  takes  more 
time. 

We  envision  this  sort  of  capability 
(wnlch  ultimately  provides  Interactive 

access  to  an  on-line  User's  Manual)  as  the 
first  step  towaru  a  helpful  system.  This 
"Help*  facility  must  provide  terse 
reminders  for  experienced  users  who  have 
momentarily  forgotten  something,  verbose 
explanations  (e. g. ,  selections  from  a 
User'*  Manual)  for  naive  users,  as  well  as 
an  Interface  with  the  actual  Tutorial 

segment  described  below.  It  must  allow 
the  user  to  interact  to  select  what  he 
wants  to  see,  while  recognizing  enough  of 
his  state  to  make  reasonably  accurate 
first  guesses  to  minimize  such 
Interact  ions .  It  must  also  allow  easy 
ways  for  the  user  to  ask  for  help  at 
higher  or  lower  levels:  for  example,  a 
request  for  help  wh«*n  typing  a  command 
might  yield  a  description  of  that  command, 
whereas  the  user  realiy  wanted  either 
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alternate  commands  or  details  of 
particular  parameters  to  that  command. 

The  Tutor  provides  help  on  request. 
Introduces  users  to  new  aspects  of  the 
service.  Interprets  service  errors  for  the 
user,  and  provides  User  Manuals  at  various 
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Though  the  value  of  human  classroom 
teaching  and  personal  tutoring  should  not 
be  underest i mated ,  sooner  or  later  a  user 
is  required  to  do  something  wi th  the 
system  for  whlcn  he  has  not  been  trainee. 
Ihe  only  i ns t rue t i ona I  aid  that  we  can 
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The  majority  of  existing  CAI  systems 
eitner  are  oriented  toward  teaching  some 
specific  subject  or  provide  languages  in 


which 

1 nstruct lonai 

programs 

(or 

a lessons 

9)  can  be  written.  The 

former 

approach 

Is  I nappropr late 

for  an 

open- 

ended 

system  like  CONNECT  that 

must 

provl de 

for  arbitrary 

services. 

The 

latter  Is  a  feasible  approach!  however, 
the  designer  of  a  service  module  should 
not  be  required  (or,  more  to  the  point, 
expected)  to  write  CAI  lessons,  since  this 
Is  tangential  to  his  major  goal.  It  may 
be  possible  to  make  the  CONNECT  Tutor 
table-driven  hy  a  description  of  the 
particular  service.  though  this  requires 
further  research. 

The  Tutor  is  designed  both  as  an 
extension  of  the  Help  system  (so  that  If 
the  User's  Manual  is  I nsu f f i c i ent  to 
resolve  a  user's  confusion,  he  can  ask  for 
a  lesson  on  the  subject  in  question)  and 
as  an  introduction  to  the  system  as  a 
whole  or  to  a  given  n>oau  I  e  or  command. 

Essential  to  our  concept  of  the  Tutor 
is  a  recognition  of  the  need  for  the  user 
To  get  his  hands  on  the  system  and  try 
things.  Ideally,  the  Tutor  should  provide 
tne  quivalent  of  an  interactive  classroom 
(or  tutored)  lesson,  and  th  r  allow  the 
user  to  experiment  with  the  system  as  If  a 
human  tutor  were  looking  over  his 
snou l der . 
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Of  the  two  apparent  ways  to  Implement 
this,  the  f I r st--havi ng  the  Tutor  sirmj  ate 
the  commands  that  the  user  trles--has  been 
discarded  In  the  he  lief  that  It  can  only 
lead  to  an  ultimate  disparity  between  the 
system^s  behavior  as  simulated  by  the 
Tutor  and  the  actual  system's  behavior 
once  the  user  leaves  the  Tutorial.  In 
order  to  avoid  the  inevitable  loss  of  user 
confidence  that  would  result,  we  are 
seeding  to  provide  the  Tutor  with  a 
"monitor*  mode  in  which  it  can 
experimentally  pass  the  user  off  to  some 
service,  allow  him  to  execute  commands 
"safely,"  ana  insure  that  i he  Tutor  can 
always  maintain  control.  !•.  a  sense  this 
allows  the  Tutor  to  simulate  the  system  Dy 
using  tne  system  itself. 

This  approach  greatly  eypands  the 
possibilities  for  the  Tutor:  it  can  lead 
the  user  through  trials  ana  examples  In 
which  re  ;s  actually  using  the  system. 
This  capability  may  be  able  to  greatly 
reduce  the  gap  oetween  classroom 
instruction  and  actual  hands-on  use,  an-'' 
wi  I  I  make  the  system  behave  far  more 
helpfully. 

In  summary,  the  Tutor  seeks  to  make 
the  system  intelllqlole  to  the  user  by  (I) 
providing  an  on-  or  off-line  User  Manual 


for  that  part  of  the  service  which  the 
user  is  Interested  in,  (2)  answering 
questions  about  the  service,  (3)  teaching 
the  user  to  do  new  things  with  the 
service,  and  (4)  translating  all  service 
error  messages  into  terms  the  user  can 
understand. 

PROJECT  STATUS 

The  project,  which  consists  of  three 
phases,  is  currently  in  the  latter  stages 
of  the  first  phase  and  entering  the 
second.  Each  phase  is  scheduled  to 
require  about  six  months  for  completion. 

The  first  phase  is  t,.e  design  of  a 
model  system  that  will  ref  lect  the  state 
of  the  art  with  respect  to  human- fac tor s 
technology  and  the  methodoloqy  described 
in  this  section,  as  well  as  Incorporate 
tne  two  aoals  for  tne  resulting  system: 
first,  'hat  it  be  a  demons t r at  I  on  service 
to  exhibit  and  evaluate  that  technology; 
second,  that  it  be  an  exper I mentat i on 
vcr.icle  to  develop  a  new  methodoloqy. 

Phase  two  is  implementation.  Durlnq 
the  seccrid  phase  the  project  wi  II 
implement  the  model  system  on  the  POP  10 
under  the  TENFX  operating  system,  using 
the  BL ISS-10  programming  languaqe. 
Fortran  will  also  be  used  for  much  of  the 


SUMMARY 


statistical  analysis  done  t>y  the  User 
Monitor.  Because  of  a  ml  I d  interest  In 
trans ferabi 1 1 ty ,  all  operating  system 
cal  is  wi  I  I  oe  restricted  to  one  rrodule. 

Phase  three  Is  the  experiment  and 
evaluation  phase.  The  currently  planned 
experiments  deal  with  different  language 
forms  which  can  oe  provided  to  the  user. 
These  Include  functional  notations, 
computer -di rected  dialogue,  multiple- 
choice  commands,  function  keys,  sub¬ 
commands  (key  word  macros) ,  etc  The 
goai ,  as  described  under  the  User 
Monitor,  will  be  to  match  various  user 
char ac ter i st i cs  to  the  different  language 
forms.  The  evaluation  phase  will  address 
Doth  the  suitability  of  the  model  system 
as  a  production  paradigm  to  be  used  in 
directing  grand  or  production  targets  and 
its  app 1 1 cabi I i t y  as  a  human-f actor s 
testing  facility.  The  expected  future 
efforts  should  Include  both  the  more 
pr oduct i cn-or i erted  goal  of  deliver' ng 
complete  command  and  control  message 
services  and  the  put  suit  of  research  Into 
user's  needs. 

SUMMARY 

The  main  goal  of  the  Information 
Autonation  project  is  to  e<tend  the 


benefits  of  computer  technology  and 
methodology  to  users  of  written 
information,  delivering  these  benefits  in 
a  way  that  users  find  convenient  and 
helpful.  The  primary  emphasis  of  the 
proposed  system  design  Is  people 
efficiency  rather  than  machine  efficiency. 
It  Is  the  conviction  of  the  project 
personnel  that  general  purpose  but 
nontunable  services  do  not  solve  these 
types  of  problems.  Hence,  CONNECT  makes 
It  possible  to  efficiently  generate 
specialized  simple  services  for 

communl cat  Ions  applications  by  means  of 
continuous  measurement  and  adaptation. 

Though  some  of  the  a  x>ve  Ideas  are 
nor  new ,  they  have  not  yet  been 
successfully  combined  into  an  Integrated 
service  for  use  by  people  unfamiliar  with 
computers.  In  fact,  the  attempt  to  design 
a  human-engi neer ed  service  Is  a  relatively 
recent  one.  Attempts  in  this  direction 
are  prone  to  many  pitfalls,  particularly 
the  failure  to  understand  in  sufficient 
depth  and  breadth  the  true  needs  of  the 
prospective  user  population.  CONNECT  wi  II 
attempt  to  avoid  these  pitfalls  by 
careful,  ongoing  attention  to  the  needs 
and  requirements  of  specific  user  groups. 
A  prototype  CONNECT  service  should  be 
available  on  the  ARPANET  early  in  1975. 
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INTRODUCTION 

The  development  cf  a  digital  means 
for  secure  speech  transmission  is  a  very 
high  priority  military  goal.  The  iSI 
network  secure  speech  project  is 


attempting  to 

estab 1 

ish 

secure. 

hi  qh- 

qua  1 i ty,  rea 

1  -tl me. 

full -cup  1  ex 

voi  ce 

co^nuni cation 

usi  ng 

the 

ARPANET  as  a 

transmission  channel. 

The 

r esu 1 t i ng 

vo?  ce 

communi ca t i ons 

sys  tern 

vi 

1 1  have 

the 

following  advantages! 

1  )  It  can  be 

secured 

(encrypted)  to  any 

desl red 

1  eve  1 

of 

complexity  and 

secur 1 ty. 

si  nee 

i  nf  1  ni tel  / 

many 

coding  schemes 

exl  st 

that  can  be 

readily  applied  to  a  digital  signal. 


2)  If  desired,  extremely  high  quality  and 
iov  error  rates  can  be  achieved 


(although  possibly  at  the  expense  of 
substantia i I y  higher  data  rates). 

J)  Packet-svi tched  comrouni cat i on  can 
exploit  the  natural  pauses  and  breaks 
in  human  speecn  in  order  to  achieve  a 
lover  overall  data  rate.  Because 
packet-switching  methods  used  in  the 
ARPANET  are  asynchronous,  however, 
the  received  speech  will  be  delayed 
slightly,  since  it  must  be  assembled 
synchronous  1 y. 

4)  Such  a  voice  communications  method 
will  be  highly  compatible  with  future 
communications  systems  (such  as 
satellites,  lasers,  packet  radio, 
etc.)v  ail  of  which  will  be  digital 
and  many  of  which  will  be 
packet-svl tched. 
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PACKET-SWITCHING  NETWORKS 

Packet  switching  offers  more 
efficient  use  of  communication  chan  it  Is 
than  circuit  switch!  nq.  It  Is  suited  for 
voice  communication  because  of  its 
intrinsic  nature,  i.e.,  of  achieving  any 
given  rate  by  using  short  bursts  of  higher 
rate.  This  technique  by  its  very  nature 
takes  advantage  of  the  variable  data  rate 
in  human  speech  (long  vowels,  silence 
periods,  etc). 

The  philosophy  behind  packet 
switching  is  that  the  highest  reliability 
can  be  achievec  by  error  detection  and 
retransmission  when  necessary,  which 
allows  reliability  to  be  as  high  as 
desired  at  the  oossible  cost  of  delays  and 
banowioth.  Since  voice  cormuni ca t i on 
cannot  tolerate  arbitrary  gaps  and  delays, 
the  ARPANET'S  pi esent  definition  of 
reliable  transmission  must  be  modified 
and  transmission  procedures  changed 
accordi ngl y. 

Special  protocols  are  oevelcped  for 
voice  communi cat i or  independent  of  the 
specific  voc.odlng  techni  gat  being  used. 
In  fact,  a  part  of  the  protocol  is  to 
make  sure  that  both  parties  use  the 
same  vocodi ng  technique.  The  same 
communication  protocol  wi  1 1  be  used  for 


LPC  (Linear  Prediction  Coding),  CVSD 


(Cont I nuous 

Var  J  abl e 

S  lope 

Del  ta 

modu lat i on) , 

and  any 

other 

vocodi ng 

techni quo. 

VOCOUiNG 

In  order 

to  achieve 

di qi ta 1  voi ce 

communications  over  the 

ARPANEl 

,  i  t  wj  |  i 

be  necessary 

for  the  data 

rate  requi reo  to 

be  as  low  as 

possible  in  order  to 

mi  ni mi ze 

the  load  on 

the  network; 

some 

type  of 

bandwidth  compression  (called 

vocodi  ng 

when  applied 

to  speech) 

wi  1  1 

thus  be 

required.  An  extensive  study  of  available 
vocoders,  both  hardware  i mpl emer.tat i ons 
and  software  algorithms,  determined  that 
present  hardware  vocoders  are  inflexible, 
expensive,  and  of  insufficient  quality. 
It  was  therefore  oeciced  to  implement  the 
best  available  software  vocodt;  usinq  a 
powerful  general-purpose  signal-processing 
machine.  Following  the  evaluation  of 
several  signal  processors,  a  Signal 
Processing  Systems  was  purchased, 

along  with  a  POP-ll/^S  to  drive  it  and 
handle  communications  with  the  ARPANET. 
Software  support  .1  forts  for  these  two 
machines  will  be  cescribed  in  the  final 
part  of  this  section. 

The  software  vocodi ng  method  chosen 
for  i mp I ementat i on  was  LPC  (Linear 
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Predictive  Coding),  specifically  the 
version  developed  at  the  Speech 
Common i  cat  1  on  Research  Laboratory  (SCRL) 
In  Santa  Barbara  [1].  Off-line  simu¬ 
lations  have  shown  that  relatively 
hi gh-oua i i ty  speech  can  be  transmitted  at 
a  data  rate  of  around  3kb/sec  using  LPC. 
LPC  requires  much  less  computation  than 
other  known  vocodi ng  methods,  with 
superior  quality  and  the  same  data  rate* 
It  is  important  to  note,  however,  that 
the  vocodi ng  method  and  the  network 
communications  algorithms  will  be  inde¬ 
pendent  of  each  other.  i he  latter 
will  be  optimized  to  take  full  advantage 
of  the  properties  of  speech,  but  not  the 
properties  of  the  particular  vocodi ng 
method  itself.  Should  the  speech  research 
community  develop  a  vocodi ng  method  that 
is  clearly  superior  to  LPC  (no*,  likely  In 
the  net'  future),  the  vocodi ng  method 
could  be  changed  without  changing  the 
network  communications  software. 

The  real-time  LPC  vocoder  will  be 
Implemented  In  the  following  steps! 

1)  An  off-line  floating-point  simulation 
on  TENEX,  undertaken  to  familiarize 
project  personnel  with  the  LPC 
algorithm  and  Its  Implementation,  Is 
almost  complete. 


2)  An  off-line  Integer  simulation  will  be 

implemented  on  TENEX.  This  must  be 
done  in  order  to  insure  that  problems 
with  the  lb-bit  integer  structure  of 
the  SPS-^1  will  be  minimized  and  to 
verify  that  results  from  the  SPS-^1 
are  correct. 

3)  The  resulting  algorithm  will  be 

implemented  to  run  in  real  time  on 
the  SPS-^l/POP- 1 1  system.  Because  of 
the  highly  complex  programming 
structure  of  the  SPS-^l,  this  step 
will  probably  require  much  mere  time 
and  effort  than  the  previous  two 
steps. 

SPECIAL  PROTOCOLS  FOR  VOICE  COMMUNICATION 

The  communi cat i on  protocol  to  be  used 
for  voice  transmission  has  two  components! 
control  and  data  transfer. 

The  control  component  of  the  protocol 
is  responsible  for  performing  the 
connection  *0  the  right  party  and 
generating  the  equivalent  of  a  “busy"  tone 
or  a  "ring"  tone  at  the  originator  and  the 
equivalent  of  a  telephone  bell  at  the 
answering  party.  It  is  also  responsible 
for  making  sure  that  the  vocodi ng 
techniques  used  are  compatible,  and  for 
negotiating  some  options. 
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Later,  when  conferencing  is 
implemented,  the  control  component  will 
also  be  responsible  for  “Conference 
Control”  (the  chairmanship).  It  will 
direct  voice  output  from  the  speaker  to 
all  the  conference  participants  and  direct 
control  signals  from  the  chairman  (a 
person  or  a  program)  to  all  participants 
to  inform  them  when  a  participant  wi II 
become  the  speaker.  Other  signals  will 
tell  the  chairman  who  wants  to  speak  at 
any  time. 

The  data  transfer  component  is 
.  esponsible  for  transferring  the  data  from, 
the  speaker  to  the  list«ner  at  the  best 
combination  of  minimum,  delay  and  highest 
bandwidth.  I  his  wi  I  1  be  accomp I i shed  by 
continuous  monitoring  of  the  network 
performance  on-line  and  by  adaptinq  the 
transmission  parameters  to  the  variable 
network  characteristics.  The  transmitting 
party  wi  »!  measure  the  delays,  bandwidth, 
and  actual  number  of  parallel  links 
available  to  the  destination,  and  adapt 
Itself  accordingly.  The  receiving  party 
will  self-Impose  a  voluntary  delay  in 
order  to  maintain  better  continuity 
(smoothing)  of  the  output.  This  delay 
will  vary  according  to  the  network 
performance  as  measured  on-line. 


ELF  Am l  SPS  SUPPORT  IMG  EFFORTS 

The  software  environment  for 
Implementation  of  voice  protocols  will  be 
provided  by  LLr ,  an  operating  system 
created  by  SCRL  that  Is  undergoing 
continued  development.  User  processes 


r unni ng 

under  llF  will 

control 

the 

vocod  i  nv] 

algorithm  on  the 

SPS-M 

and 

interface  to  the  ARPANET  using  the  special 
voice  protocols.  An  additional  user 
process  will  handle  cebucqing  facilities 
for  the  SPS-4 l . 

Hi  nor  modifications  to  ELF 's  network 
control  program  will  support  those  aspects 
of  voice  proto<_«,is  that  differ  from 
standard  ARP A  host-host  protocol  and  will 
supply  facilities  for  measuring  network 
timing  character i st i cs  during  voice 
transmi ss i cn. 

Both  ELF  and  SPUD  (Signal  Processing 
Unit  bebuqger)  have  been  modified  to 
support  ISl's  POP- 11/45  configuration,  and 
each  is  operational  independently.  Work 
currently  in  progress  Includes  conversion 
of  SPUD  to  run  as  an  ELF  process,  addition 
of  a  process  to  measure  network  timing 
character i st Ics  as  perceived  by  hhe 
POP/ 11,  Implementation  of  a  CVSQ  '  ocoder 
on  the  SPS-A1,  and  final  checkout  of 
hardware  built  at  ISI  (POP-ll/IttP 
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Interface  i  nd  A/D  and  D/A  converters  for 
the  SPS-' 

VI  rt  al  l  program  support  other 

than  debuggi.g  Is  handled  by  programs 
under  TENEX.  lupport  programs  In  use  by 
the  speech  project  Include  an  assembler 
for  SPS-41  programs.  Bliss- 11,  MACNU,  and 
many  utility  programs.  MACNIl's 
facilities  for  assembling  PDP-11  programs 
have  been  substantially  augmented  by  ISI 
and  SCRL,  and  Its  development  Is 
cont> nui  ng. 

SUMMARY 

Diqltal  voice  transmission  can  be 
made  as  secure  and  as  reliable  as  desired. 
Because  of  Its  Inherent  asynchr or oui 
nature,  packet -svl t chi ng  technology  is 
naturally  suited  to  voice  transmission. 
Therefore,  developing  the  means  to  use  a 
packet-svl tchl ng  network  for  digital  voice 
transmission  Is  an  effort  of  great 
potential  usefulness  to  the  military 
conumml  ty. 


Our  work  In  this  area  Is  performed  In 
close  col  I aborat 1  on  w' th  the  ARPA-NSC 
(Network  Secure  Comm jnl cat  1  on)  group, 
particularly  with  the  Speech  Communication 
Research  Laboratory  of  Santa  Barbara, 
mentioned  above. 

Our  major  role  in  this  effort  is 
establishing  the  methoaology  of  using  the 
ARPANET  for  this  project,  and  Implementing 
it  with  real-time  vocodl ng  to  prove  the 
feasibility  of  using  packet-switched 
digital  networks  for  secure  voice 
communications.  Presently,  our  efforts 
are  aimed  at  (1)  performing  network 
measurements  for  the  development  of  the 
protocols  required  for  real-time  voice 
communications  and  (2)  implementing  LPC, 
both  on-line  and  off-line.  The  next  stage 
of  effort  will  be  to  optimize  the 
communication  protocols  and  improve  the 
quality  and  reduce  the  bandwidth  of  the 
vocoding  technique. 
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INTRODUCTION 

This  section  describes  three  of  the 
major  advance^  hardware  systems  being 
developed  at  IS  I .  Each  of  these  hardware 
efforts  was  undertaken  In  response  to 
research  support  requirements  and/or  to 
demonstrate  a  capability  for  a  recognized 
DoD  application.  As  mentioned  earlier, 
they  are  also  being  developed  as  necessary 
support  Items  for  the  several  software 
projects  that  compose  the  Network 
Co nvaunl  cation  Technology  effort.  The 
projects  Include  the  Xerox  Graphics 
Printer  (a  high-quality  document  printing 
capability  In  the  form  of  a  network 
terminal),  the  Video  Display  System,  and 
Portable  Terminals. 

XEROX  GRAPHICS  PRINTER 

Two  Xerox  Graphics  Printers  (XGP's) 
are  now  In  operation  at  ISI  as  terminal 


devices.  Each  XGP  Is  attached  through  a 
PDP-11 /AO  to  tne  POP- 10  via  a  2400-baud 
data  link.  The  PDP-11/4G,  with  a  modified 
version  of  the  software  designed  at 
Carnegl e-Me lion  University,  will  drive  the 
XGP  and  provide  hard-copy  output  T.z... 
files  on  the  POP-10.  The  PDP-11  acts  as  a 
data  buffer  and  line  "raster I zer," 
providing  v I deo  data  and  synchronization 
to  drive  the  XGP  through  an  ISI-desIgned 
Interface.  The  Interface  design,  based  on 
a  design  originally  conceived  for  ARPA  at 
the  University  of  Utah,  has  been 
repackaged  and  Improved,  resulting  In  a 
f actor-of-four  reduction  In  package  size 
and  an  increase  In  reliability  and 
per  for  mane  e. 

One  of  the  XGP  systems  Is  being 
shipped  to  the  ARPA  office  In  Washington, 
D.C.  and  attached  to  a  Terminal  Inter¬ 
face  Processor  (TIP)  there  to  provide 
high-quality  on-line  hard  copy.  The 
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system  remaining  at  ISI  will  be  used 
experimentally  to  develop  a  two-speed 
version  of  the  copier  capable  of  providing 
(I)  a  high-quality  output  at  300  lines  per 
Inch  resolution  and  0.5  Inch/second  paper 
speed  and  (2;  a  lower -qua 1 1 ty  output  at 
100  lines  per  Inch  resolution  and 
approxl  matel y  2  inch/second  paper  speed. 
Presently,  the  system  runs  at  196 
llnes/lnch  resolution  and  0.67  inch/second 
paper  speed.  When  the  experimental  system 
Is  completed,  hardware  and  software  will 
be  retrofitted  to  the  system  In  the  ARPA 
office;  if  the  system  modification 
provides  a  useful  function.  It  will 
pr ooably  be  incorporated  Into  future  XGf 
systems  supplied  by  the  Xerox  Corporation. 
The  schedule  for  completion  of  two-speec 
fix'd!  f  1  c,  r Ion  to  the  ISI  roach  ne  Is  late 
fail  of  19  . 

VIDEO  *PI.AY  SYSTEM 

The  development  of  the  Video  Display 
System  Is  continuing  as  previously 
reported  [lj.  The  system  design  provides 
an  Inexpensive  hi  gh-qual  1  ty  tern.ir.al 
for  computer  users  (l.e.,  programmers, 
managers,  and  secretaries)  who  require 
si  gnl  f  1  cant  I  y  more  capabilities  than 
are  currently  available  with  low-cost 
terminals.  These  Include  a  full  page  of 


text  (more  than  4000  characters), 
graphics,  256  characters  of  writable  font, 
and  a  stardard  communications  Interface  to 
facilitate  computer  connection.  A  modular 
design  (part  of  the  stated  requi rements) 
will  make  it  possible  to  use  components  In 
a  clustered  envircnment  as  well  as  in  a 
remote  stand-alone  unit,  with  a  minimum 
cost  di f ferentl a  1 .  A  contract  for  the 
system  has  been  let  to  System  Concepts, 
Inc.  of  Palo  Alto.  Internal  problems  of 
that  firm  have  delayed  completion  of  the 
system  by  one  year — first  deliveries  are 
now  expected  in  the  first  quarter  of  1976. 
Alternative  suppliers  are  being  examined, 
and  the  question  of  how  to  provide  the 
desired  high-quality  terminal  system  Is 
being  recons i dered. 

As  art  interim  measure,  ISI  has  leased 
Beehive  terminals,  a  video-based  tele¬ 
type  replacement.  These  terminals  are 
standard  equipment  in  each  full-time  pro¬ 
fessional's  and  each  secretary's  office; 
in  addition,  several  public  terminals  are 
available  for  graduate  students,  consu 1 - 
tants,  and  other  part-time  personnel. 

One  major  effort  during  the  year  was 
the  design  of  the  keyboard  layout  for  the 
proposed  terminal  system.  We  required  the 
keyboard  to  generate  the  128  seven-bit 
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standard  ASCII  characters  In  an  el  oil  bit 
field  (to  be  compatible  with  the  ARPANET). 
The  American  National  Standards  Institute 
has  proposed  two  standards  for  ASCII 
keyboards  (proposed  standard  X4A9/199B)* 
one  with  "logical  bit  pairing^'  and  t‘,« 
other  with  "typewriter  pairing."  But,  in 
either  case,  the  standard  defines  only  the 
"inboard"  area  containing  the  alpha- 
numerics  and  punctuation  symbols*  the 
layout  of  the  "outboard  control  are<i" 
(e.g.,  eturn,  Oelete,  Control)  Is  left  to 
the  designer.  Thus  we  had  three  topics  on 
which  further  design  was  necessary •  which 
of  the  two  standard  keyboards  to  choose, 
the  design  of  the  outboard  control  area, 
and  the  method  by  which  the  operator  can 
produce  the  128  other  characters  permitted 
by  the  eight-bit  field  generated  by  the 
keyboard. 

Most  computer  terminals  use  the 
logical  bit  pairing  principle,  which 
specifically  pairs  characters  on  a  key  so 
that  there  Is  a  single-bit.  difference 
between  the  Internal  ASCII  code  reore- 
sentatlons  of  the  characters.  This  was  an 
early  design  decision  made  to  ease  the 
construction  of  older  e 1 ectrcmechani ca 1 
keyboards;  current  technology  permits  more 
flexibility,  and  so  we  have  chosen  the 
typewriter  pairing.  A  number  of  our 


projects  envision  the  use  of  the  terminal 
in  standard  office  environments  as  an 
Individual's  first  personal  contact  with  a 
computer.  The  typewriter  pairing  wl  l  i 
ease  the  transition  to  the  terminal  and 
permit  easy  switching  back  and  forth 
between  typewriter  and  terminal. 

Our  design  for  the  outbc.  control 
area  is  similar  to  that  found  on  a  number 
of  ASCII  terminals.  Two  exceptions  are 
that  the  Infrequently  used  Line  Feed  key 
was  moved  to  the  edge  of  the  keyboard,  and 
an  Alpha  Lock  key  (which  locks  only  the 
alphabetic  keys  to  upper  case)  was 
substituted  for  the  normal  Shift  Lock  key. 
Included  In  the  outboard  control  area  are 
Case  II  keys,  a  Control  II  key,  and 
appropriate  Lock  keys.  When  activated, 
these  keys  shift  the  entire  keyboard  (with 
the  exception  of  the  formatting  keys  like 
Space  and  Return)  Into  a  "third*  case,  and 
perral t  the  generation  of  the  upper  128 
A SCll  codes  (octal  200-377).  Finally,  the 
keyboard  Includes  explicit  Tab  and  Back 
Space  keys,  as  well  as  a  key  labelled 
"Help,"  which  will  cause  ISI-desIgned 
software  to  take  tutorial  action. 

Another  major  effort  during  the  year 
has  been  work  on  a  standard  protocol  for 
controlling  the  proposed  terminal.  A 
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major  start  on  an  acceptable  protocol  has 
been  made  by  the  ARPANET  Network  Graphics 
Group,  chaired  by  Jim  Ml chener  of  Project 
MAC  at  the  Massachusetts  Institute  of 
Technology.  institute  efforts  have  been 
devoted  £o  under st andl ng  this  protocol, 
especially  wl  tn  a  view  to  any  hardware 
features  It  might  suggest,  and  cooperating 
with  Robert  Sprou 1 1  of  Xerox  Palo  Alto 
Research  Center  and  Charles  Irby  of  the 
Augmentation  Research  Center  of  Stanford 
Research  Institute  In  refining  It.  Irby 
especially  is  the  major  designer  of  the 
“positioned  text"  portion  of  the  protocol, 
the  part  in  which  the  Institute  Is  most 
interested.  The  positioned  text  protocol 
permits  the  programmer  to  divide  the 
display  screen  Into  “windows*  and  to 
manipulate  text  Independently  within  each 
window.  For  example,  in  a  text-editing 
application,  four  separate  windows  might 
be  used  for  messages  from  the  system, 
command  entry  and  feedback,  the  file  being 
edited,  and  a  file  of  connections. 

As  mentioned,  we  have  been  especially 
interested  in  designing  hardware  features 
for  our  terminal  system  that  would  ease 
the  I mpl ementatlon  of  the  protocol.  The 
most  significant  area  in  which  hardware 
can  help  is  with  the  windows,  especially 


Independent  scrolling  of  side-by-side 
windows  and  automatic  actions  at  window 
boundaries.  Our  most  promising  Idea  is  to 
organize  the  display  character  buffer  as  a 
list,  with  pointers  and  lengths  being 
separate  from  the  characters.  Independent 
window  manipulations  can  then  be 
accomplished  ty  relatively  quick  manip¬ 
ulation  of  the  pointers  instead  of 
time-consuming  rewrites  of  major  portions 
of  the  character  buffer.  Finally,  we  are 
working  on  Including  new  character  fonts 
In  the  protocol  to  take  advantage  of  the 
hardware  proposed  for  the  ISI  terminals. 

PORTABLE  TERMINALS 

Since  its  Inception  last  year,  the 
goal  of  this  project  has  been  the 
development  of  a  portable  terminal  device 
able  to  communicate  from  any  telephone  to 
any  ARPANET  site,  permitting  mobile  users 
to  e»  ;ly  take  advantage  of  mail,  message, 
and  other  ARPANET  services.  In  July  of 
1973,  a  prototype  portable  terminal  was 
delivered  to  ARPA  and  has  been  functioning 
since  then  free  of  additional  maintenance. 
The  unit  weighs  20  pounds  and  is  enclosed 
in  a  small  briefcase  (10"  x  14“  x  6")  that 
can  fit  comfortably  under  an  airplane 
seat  (see  Figure  8.1).  In  contrast, 
conventional  portable  display  terminals 
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Figure  8.1  The  ISI  portable  terminal 
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weigh  nearly  twice  as  much  and  are  bulky 
and  unwieldy  to  carry. 

The  ISI  terminal  Is  built  entirely  of 
standard  of f-the-she 1 f  components.  It 
uses  a  53-key  electronic  keyboard,  built- 
in  acoustic  coupler,  and  a  Burroughs 
Corporation  Self-Scar,  panel  display  unit 
with  «.  lines  of  32  alphanumeric  upper-case 
character s  ( 256-character  display). 

This  terminal  Is  intended  primarily 
as  an  evaluation  Instrument  to  help  In 
defining  the  functional  capabilities 
required  of  second-generation  portable 
terminals.  he  critical  areas  of  the 
present  design  have  been  found  to  be  its 
limited  visual  context  and  Its  size  and 
weight  parameters.  The  optimum  tradeoff 
between  minimum  size  and  maximum  display 
area  Is  now  being  empirically  defined. 

In  an  attempt  to  Improve  these 
critical  areas  of  design  and  also  to  gain 
Insight  into  alternatives  to  the  Burroughs 
display  pane),  two  plasma  panels  have  been 
purchased  from  Owens-I  1 1 i noi s  Corporation. 
These  are  roughly  comparable  In  size  and 
vei gnt  to  the  burroughs  panel,  but  their 
40 -character -per- 1 1 ne  format  is  much  mere 
compatible  with  the  60 -character  lines 
generated  by  IlNEX  (nearly  doubling  the 
line  display  capability  of  the  terminal). 


The  Owens-Illinois  panels  will  be  used  In 
two  further  prototype  portable  terminals 
that  will  Incorporate  the  following 
additional  design  refinements*  upper-  and 
lower-case  characters.  Increased  visual 
context,  smaller  power  supply  weight, 
smaller  keyboard  size  and  weight,  and 
resulting  smaller  overa  11  weight. 

When  these  tvo  prototype  terminals 
are  completed,  the  project  will 
concentrate  upon  the  most  critical  of  the 
problem  areas  so  far  Identified*  the 
display  screen.  Liquid  crystal  displays, 
which  could  provide  a  lightweight, 
low-power ,  e lectromagnet i c-radl atlon-free 
substitute  for  CRT  terminals,  look 
feasible  for  the  portable  terminal 
application.  They  seem  to  greatly  reduce 
electrical  power  requ I rements,  although 
with  a  proportional  decrease  In  writing 
speed.  An  optimum  tradeoff  between  power 
demands  and  writing  speed  requirements 
will  need  to  be  Identified.  The  liquid 
crystal  technology  no*  existing  In 
industry  will  probably  be  capable  of 
providing  a  usable  display  panel  within 
two  years  if  this  project  can  provide 
proper  encouragement  and  direction  by  de¬ 
fining  specific  military  requirements  and 
perhaps  providing  financial  assistance. 


94 


REFERENCE 


Annual  lechni  cal  Report ,  May  1  972  -  May  _1_973,  USC/  Informat  Ion  Sciences  Institute, 

IWSR-73-lV  I  973. 


95 


9 


NETWORK  MANAGEMENT  INFORMATION  CENTER 

PROJECT  LEADERS  Stephen  R.  Klmfcleton 
PROJECT  SUPPORTS  Linda  K.  Tisnado 


INTRODUCTION 

The  Network  Management  Information 
Center  (NMIC)  was  established  on  March  4 , 
1974.  Its  objective  is  to  provide  a 
co npr enens i ve  base  for  network  management. 


to  develop 

pol ici es 

and 

procedures  for 

concurrent 

operat ion 

of 

Networ  k 

Cont  ro i 

Center s 

(NCCs). 

and 

to 

oeve lop 

requirements  and  staffing  character J sti cs 
for  minimum-manpower,  mi ni mum-sk i  IJ -  I  eve  I 
NCCs.  To  ensure  the  feasibility  of  the 
approaches  developed,  the  Initial 
objective  will  be  to  establish  a  backup 
NCC  for  the  currently  existing  Nf.C  at  Bdh 
which,  on  a  scheduled  Dasis,  will  be 
capable  of  assuming  responsibility  for 
detecting  outages  and  performing 
appropriate  not  * f i cat  Ions  to  accomplish 
their  repair. 

Accomplishing  this  initial  objective 
will  require  a  significant  level  of 
effort.  The  potential  reward  to  oe 
achieved  is  large  when  measured  In  terms 
of  reliability,  efficient  resource  use, 
and  ability  to  accommodate  rapidly 


changi ng  workloads  such  as  occur  in  stress 
situations  for  command  and  control 
1 nstal lations.  A  framework  for  developing 
the  total  requirements  of  NCC(s)  is 
needed.  The  following  remarks  provide  one 
approacn  to  the  development  of  such  a 
framework.  It  is  to  be  anticipated  that 
this  approach  will  oe  critically  examined 
during  the  implementation  of  the  initial 
phase  discussed  above. 

The  ARPANET  interconnects  equipment 
provided  by  most  of  the  major  mainframe 
vendors,  permits  effective  snaring  of 
these  resources  by  a  widely  varying  user 
population,  and  serves  as  a  research 
vehicle  for  directing  and  evaluating 
potential  network  technologies  such  as 
packet -sw! tched  radio  and  satellite 
communication.  As  a  result  of  str^p^  user 
demands  for  the  latest  advances  In 
computing  technology,  high  reliability, 
and  ease  of  interface,  management  of  the 
ARPANET  is  an  exceedingly  difficult  task. 

The  difficulty  of  ARPANET  management 
is  increased  by  the  nearly  exponential 
growth  In  network  traffic  [I],  the 
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Increasing  demand  within  the  DoD  community 
f or  access  to  the  network,  and — because  of 
budgetary  II  ml tations--the  requirement 
that  ARPA-supported  hosts  operate  near  or 
above  the  utilization  levels  at  which 
effective  service  can  be  rendered. 

Computing  economies  achievable  through 
resource  sharing,  coupled  with  the 

opportunities  resource  sharing  affords  to 
provide  services  previously  unachl evable, 
e.g.,  the  National  Software  Works  (2,33, 
render  it  unlikely  that  this  trend  In 

usage  will  reverse.  Thus,  the  requirement 

for  efficient  network  management  Is  of 
increasing  Importance.  The  need  for  this 
capaDility  is  Increased  oy  its  relevance 
to  all  or gani zat ions  possessing  large 
collections  of  computer  systems.  Indeed, 
within  the  DoD  several  mu  1 1 i mi  I  1 i on-do  I  I ar 
examples  of  such  procurements  exist, 
including  the  World  Wide  Military  Command 
ar-j  Control  System  (WWMCCS),  the  Air  Force 
Advanced  Logistics  System  (ALS),  and  the 
Air  Force  Base  Logistics  System. 

Effective  network  management  requires 
rapid  determl nat i on  of  existing  choke- 
points,  timely  identification  of  new 
conf i gurat i ons  designed  to  eliminate  these 
chokepoints,  and  the  ability  to  determine 
the  performance  impact  of  proposed 
conf I gurat i ons  upon  both  users  and  hosts. 


estimation  of  the  performance  Impact  of 
new  technologies  must  be  available  to 
provide  for  their  smooth  integration  Into 
an  ongoing  network.  Determi nat i on  of  the 
performance  Impact  of  security  require¬ 
ments  is  necessary  to  permit  effective 
utilization  of  network  technology  by  other 
DoD  or  domestic  agencies.  Both  existing 
and  proposed  conf 1 gurat 1 ons  must  provide 
sufficient  reliability  to  encournce 
acceptance  and  continued  usage. 

NMIC  has  been  established  to  provide 
both  tools  for  the  effective  management  of 
the  ARPANET  and  a  vehicle  for  research  in 
the  management  of  computer  communi cat  I  on 
networks.  The  objective  of  this  center 
is  to  afford  a  means  for  effective 
(management)  decisionmaking  among  techno¬ 
logical  issues  in  network  management.  The 
resulting  tools  will  also  assist  network 
management  in  evaluating  or gani zat i ona I 
issues  by  determining  their  technological 
i mp I i cat i ons . 

These  capabilities  will  be  achieved 
through  a  coordinated  approach  involving 
the  establ i shment  of  an  on-line  data  base 
containing  network  information,  develop¬ 
ment  of  a  management -or i ented  Information 
display  permitting  rapid  pinpointing  of 
network  chokepoints  and  easy  fixing  of 
their  determinants  and  implications,  and 
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Implementation  of  programs  designed  to 
perm! t  rapid  examination  of  the  perfor¬ 
mance  Impact  of  alternative  network 
conf I qurat I ons . 

The  existence  of  such  capabilities 
will  be  of  significant  use  In  determining 
the  kinds,  types,  and  locations  of  network 
traffJc--a  subject  on  which  nttle  Is 
currently  known-*  tone  win  provide  advanc* 
planning  Information  to  meet  evolving 
network  needs.  In  addition,  these 
capabilities  will  provide  a  factual  basis 
for  resolving  potential  conflicts  among 
users,  hosts,  and  budgetary  constra  nts 
through  estimation  of  the  total  i(.,paci  of 
demands  or  changes  and  provision  of 
Information  to  pinpoint  reliability 
problems  and  other  difficulties  impeding 
effective  usage. 

In  addition  to  the  direct  role  they 
will  play  In  network  management,  these 
tools  will  also  be  of  si gni f i cant  I nter est 
in  several  network -re  1 ated  issues,  e.g., 
conf I gurat Ion  control,  sizing  and  tuning 
of  command  and  control  systems,  dynamic 
approaches  to  reliability,  and  peak  work¬ 
load  processing  through  dynamic  job 
migration.  Further,  the  organized  ap¬ 
proach  provided  for  displaying  and 
manipulating  of  network  performance  Infor¬ 
mation,  as  well  as  for  determining  the 
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systems  Impact  of  network  modi f Ications, 
promises  to  be  of  assistance  to  other 
network-based  research  projects. 

The  remainder  of  this  section  Is 
oevoted  to  a  fuller  discussion  of  the 
ultimate  objectives  and  approach  cf  NMIC. 
To  place  this  discussion  In  perspective 
and  to  demonstrate  that  the  present 
confused  state  of  computer  system 
performance  analysis  does  not  preclude 
an  effective  capability  for  network 
management,  we  uegin  by  reviewing  some  of 
the  major  factors  responsible  for  the 
current  somewhat  unsatisfactory  state  of 
computer  systems  performance  analysis. 


PROBLEMS  IN  COMPUTER  SYSTEMS  PERFORMANCE 
ANALYSIS 

Computer  systems  performance  has  been 
the  object  of  careful  analysis  by  a  sig¬ 
nificant  number  of  individuals  for  approx¬ 
imately  the  last  five  years.  Never¬ 
theless,  the  current  state  of  the  art  is 
generally  regarded  us  unsat  I s f actory .  In 
large  part,  this  appears  to  be  due  to 
tnree  factors;  (I)  the  ad  hoc  nature  of 
much  of  the  effort,  (2)  the  fai  lure  to 
distinguish  between  or ganl zat i ona I  and 
technological  issues  In  performance,  and 
(3)  a  lack  of  coordination  between  infor¬ 
mation  required  for  decisionmaki  ng,  data 
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requl red  to  generate  this  Information,  and 
tools  used  to  aid  in  decisionmaking. 

The  aa  hoc  nature  of  prevailing 
performance  efforts  was  strongly  in¬ 
fluenced  oy  management  expectations  that 
(1)  decreasing  hardware  costs  vou I d  grad¬ 
ually  eliminate  the  need  for  performance 
efforts  ar.d  (2)  a  •good*  system  conf 1 g- 
uration  could  he  found  which,  cnce 
obtained,  would  need  relatively  little 
adjustment.  lime  has  shewn,  however,  that 
decreasing  hardware  costs  increase  the 
complex'ty  of  the  app I i cat  ions  that  can 
usefully  Le  supported;  thus  the  demand 
rate  continues  to  outstrip  available 
capacity.  In  addition,  the  computer 
system  workload  varies  si gni f I  cant  I y  with 
time  because  of  changes  in  the  organ¬ 
ization,  its  product,  and  Its  objectives. 


Thus,  performance  must  be  viewed  as  a  con¬ 
tinuing  rather  than  a  sporadic  activity. 

Effective  utilization  of  computer 
systems  performance  methodologies  by  man¬ 
agement  requires  distinguishing  between 
or gani zat I ona !  and  technological  issues  in 
performance  [i*J*  some  of  the  topics 
relevant  to  each  category  are  indicated  in 
Table  i.  Or gani zat i ona I  Issues  have  two 
primary  character i st i cs  •  tne  inclination 
of  management  to  satisfice  rather  than 
optimize  on  these  variables,  and  the 
depende  icy  of  reasonable  values  for  these 
variables  upon  factors  specific  to  a  given 
site.  Tnus,  although  centralized  guidance 
in  the  resolution  of  or gani zat i ona 1  Issues 
can  be  provided,  a  centralized  solution  Is 
prec luded. 


TABl t  1 


ORGANIZATIONAL  AND  TECHNOLOGICAL  ISSUES  IN 
IomPuTERTysTEmT  PERFORMANCE 


Organ! zatlonal  Issues 

Unnecessary  Jobs 

Insufficiently  trained 
programmers 

Priority  structure  requirements 
Acceptable  reliability 
System  overhead 
Programming  language  support 
Data  base  capabilities 


1 echno log! ca i  Issues 

Extended  instruction  set 
More  host  memory 

Devi ce/channej  ratio 
Data  set  location 
Hardvare-compat i ble  upgrades 
Load  leveling 

Performance  impact  of  file 
backup 
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Technological  Issues,  by  contrast, 
are  capable  of  cent  lized  i  nves  t.  i  qat  i  on 
and  solution.  Sucn  an  app  oacn  requires 
coordination  of  data  gather inq,  the  Infor¬ 
mation  to  be  derived  from  thi s  data,  the 
decisions  to  be  made  oy  management ,  ana 
the  means  used  to  assess  these  decisions. 
The  cost  of  not  having  a  centralized 
approach  Is  reflected  in  the  fact  that  a 
typical  simulation  study  of  a  computer 
system  costs  $50, COO  and  requires  one 
man-year  of  effort  over  six  man-months, 
while  the  cost  of  rent.ng  the  simulator 
for  six  man-montns  wc-ula  usually  be  less 
than  $5,0 00.  The  difference  reflects 
manpower  costs  to  gather  the  data  and  the 
cost  of  execution  of  the  simulator. 

The  distinction  between  organi¬ 

zational  and  technological  Issues  is  not 
completely  invariant.  As  an  example,  if 
the  number  of  users  in  a  proposed  message 
switching  system  (5j  were  to  increase  by  a 
factor  of  five.  Doth  categories  of  issues 

would  be  affected.  However,  a  co¬ 

ordinated  approach  to  technological  Issues 
would  si gnl f i cant i y  enhance  the  capability 
of  management  to  project  the  implications 
of  such  an  increase. 

Effective  ^--cisions  among  techno¬ 

logic*!  issues  in  network  management  must 
pe  based  on  suitable  information  to  permit 


(I)  timely  detection  of  usage  trends  and 
their  det  err.*’ jnts,  (2)  better  assessment 
of  the  performance  Impact  of  mod i f i cat  I ons 
and  enhancements  designed  to  provide 
cost  effective  service,  and  (3)  factual 
resolution  of  th^  performance  impact  of 
requests  for  additional  service,'.  Thus, 
the  gathering  of  data  and  the  trans¬ 
formation  of  data  into  information  and 
information  display  must  be  coordinated. 
fine  dimension  cf  the  cost  implicit  in  not 
naving  a  coordinated  approach  is  reflected 
in  tne  cost  of  present  computer  system 
simulation  stucies  as  aiscussed  earlier. 

lhe  need  for  a  coordinated  infor¬ 
mation-based  approach  to  performance  has 
been  well  recognized  [6],  The  available 
information  on  both  management  require¬ 
ments  and  performance  technologies  is 
sufficient  to  permit  such  an  approach.  It 
has  been  argued  that  a  major  reason 

for  tne  absence  of  such  an  approach  for 
individual  computer  systems  is  the  lack  of 
leverage  in  compar i ng  the  cost  of  its 
implementation  against  the  probable 
accrued  benefits.  Networks,  however, 
provide  an  immense  leverage  pote.it  ial. 
Furtier,  their  geographical  dispersion, 
coupled  with  the  magnitude  of  the 
resources  involved,  serve  to  increase  this 
leverage.  Let  us  discuss  the  requirements 
and  implications  of  such  an  approach. 
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TECHNOLOGICAL  ISSUES  AND  NETWORK 
MANAtigrtENlr 

In  the  preceding  subsection  we 
Identified  the  distinction  between  techno¬ 
logical  and  organ! zat lonal  Issues  In 
per  for mance ;  it  is  evident  that  a  similar 
dichotomy  c.ists  for  networks.  A  major 
objective  of  network  management  should  oe 
an  effective  capability  to  resolve 
technological  issues  and  thereoy  make  it 
possible  to  determine  the  technological 
implications  of  or gani z  at  I ona I  issues. 

Management  of  technological  issues 
requires  three  functional  capabl I i t 2 es • 
(1)  a  monitor  function  that  helps  to 
identify  the  relative  "health*1  of  the  net¬ 
work,  (2)  a  detection  runction  that  helps 
to  identify  factors  responsible  for  poor 
performance,  and  (3)  a  correction  function 


that  helps  to 

i dent  I f y 

appropr i ate 

modi f i cat i ons  to 

achieve 

satis  f actor  y 

per  formance. 

The  first  function  recuires  identi¬ 
fication  of  display  variables  of  use  to 
management  in  monitoring  the  quality  of 
the  network  environment.  in  addition,  it 
requires  i nst rumentat i on  of  users  to  track 
their  evolving  requirements  and  instrumen¬ 
tation  of  the  network  to  track  its 
performance.  To  avoid  inundating  manage¬ 
ment  with  unnecessary  information,  a 


management  by  exception  approach  Is 
required  that  provides  information  on  a 
few  key  factors  to  determine  If  network 
performance  Is  acceptable. 

The  second  function  requires  a 
hierarchically  organized  data  base  on 
network  performance  that  permits  rapid 
i  dent  i  fi  cat .  ~>n  of  tf  2  determinants  and 
implications  of  network  chokepoints. 
Carefui  control  of  the  amount  ana  types  of 
information  presented  is  necessary  to 
peri.  *  *■  quick  identification  of  major 
f actors. 

The  third  function  requires  a 
capability  to  predict  network  performance 
as  a  function  of  resource  modi f i cat i ons 
that  might  be  performed.  Although  a 
network  is  very  complex,  basic  network 
research  suggests  that,  in  an  unsaturated 
network,  a  structured  consideration  of 
hosts,  TIPs/IMPs  and  transmission  links 
may  be  used  to  determine  or  predict  over¬ 
all  network  performance  in  an  effective 
manner  [7*8J.  Thus  the  requirement  to 
predict  network  performance  as  an  entity 
can  be  replaced  by  a  requirement  to 
predict  the  performance  capabilities  of 
major  resources  and  interrelate  the 
resulting  predictions  to  determine  network 
performance  in  an  unsaturateo  network. 
For  a  saturated  network,  by  contrast. 
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performance  degrades  so  rapidly  (9]  that  a 
major  objective  Is  to  reduce  load  or 
Increase  capacity  until  It  Is  belov  the 
point  of  saturation. 

The  preceding  observation  suggests 
that  management  of  technological  issues 
requires  two  basic  capabi 1 1 1 1 es •  a  report/ 
display  capability  anc  an  alternatives 
assessment  capability.  The  first  would 
permit  quick  inspection  of  existing  or 
projected  performance  and  determination  of 
the  nature  of  aeslred  modi f I  cat  Ions  to 
obtain  additional  improvement  through 
careful  hierarchical  organization  of  per¬ 
formance  information.  The  second  would 
permit  projection  of  network  performance 
for  a  proposed  conf I gurat i on. 

Determination  of  the  precise  i  n  f  or  - 
mation  to  be  displayed,  as  well  as  the 
manner  in  which  it  is  to  oe  organized  and 
stored,  requires  further  i nvest i gat  Ion. 
However,  it  is  apparent  that  at  least  four 
categories  of  information  must  be  pro¬ 
vided!  (1)  current  performance,  (2) 
present  network  resource  aval  lability,  (3) 
projected  resource  availability  (to 
coordinate  preventive  mai ntenarce  and 
other  scheduled  resource  reductions),  and 
(A)  detailed  performance  information  for 
evaluating  the  effects  of  proposed  changes 
and  determining  desirable  directions  of 


future  changes. 


The  dimensions  of  the  network  per¬ 
formance  problem  as  reflected  in  the  large 
number  of  potential  alternatives  aval  I- 
able,  the  probable  variation  in  the 
metrics  used  to  compare  a  I ternat I ves ,  the 
constraints  that  must  be  observed  in  com¬ 
paring  alternatives  (e.g.,  the  connec¬ 
tivity  of  an  IMP  in  a  network  topology) 
must  be  at  least  two,  and  the  necessity  to 
consider  alternatives  to  satisfy  organi¬ 
zational  issues  (requirements)  argues 
against  a  stra I gnt forward  (single-stage) 
approach  to  achieving  networks  with  good 
per fc-mance.  Instead,  an  Interactive 
approach  permitting  rapid  management 
investigation  of  alternative  config¬ 
urations  is  required. 


To  oe  effective,  this  approach  must 
stress  speed  in  achieving  performance 
projections,  pe, haps  at  the  cost  of  some 
slight  amount  of  accuracy.  Current 
research  (iOj  suggests  that  very  fast 
performance  prediction  for  computer  sys¬ 
tems  can  be  achieved  through  analytically 
driving  simulators.  Thus,  a  key  element 
for  rapid  prediction  of  network 
performance  is  potentially  at  hand. 

Rapid  network  performance  prediction 
also  requires  an  efficient  means  of 
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Inputting  data  descriptive  of  host  capa¬ 
bilities,  host  workloads,  IMP  workloads, 
and  traffic  among  IMPs.  This  can  be 
achieved  through  ( I )  automatic  data 
gathering,  (2)  maintenance  cf  per formance 
information  on-line,  and  (3)  inputting  of 
only  change  data  in  assessing  alternative 
conf i  gur at i ons .  No  major  technical 

obstacles  preclude  such  an  approach, 
although  organization  of  the  performance 
daca  base  will  require  careful  consid¬ 
eration.  Thus,  these  capabilities  can 
easily  be  achieved  within  the  research 
environment  provided  by  the  ARPANET.  It 
should  be  noted  that  the  use  of  artificial 
intelligence  technology  could  permit  more 
effective  management  interaction  at  a 
relatively  low  net  cost. 

Our  discussion  of  network  management 
has  been  primarily  focused  on  tne 
management  of  resources  to  meet  evolving 
workload  needs.  However,  the  capabilities 
represented  by  NMJC  also  promise  to  be  of 
substantial  use  in  other  significant 
management  concerns  directly  driven  by  the 
existence  of  the  network.  These  include 
(1)  prediction  of  network  capability  to 
handle  a  new  research  project  and  deter¬ 
mine  the  "home*  host  for  this  project,  (2) 
determination  of  network  Impact  of 
reliability  problems  and  the  nature  of 


appropriate  changes,  (3)  provision  of 
basic  performance  and  capability  infor¬ 
mation  to  other  research  projects 
predicated  on  network  existence  (e.g.. 


C0TC0  [3],  National 

Sof tware 

Works  [2, 

1 

t 

and  Network 

Secure 

Speech) 

and 

(4) 

i nvest I  gat i on 

o  f 

the  user 

I  impact 

of 

emergent  network  technology. 

RlLATEQ  bENEFITS 

Conf i duration  control,  i.e.,  the 
assurance  of  compatibility  among  programs, 
files,  and  hosts,  is  a  topic  of  continuing 
concern  to  network  management.  This  prob¬ 
lem  is  of  particular  significance  to 
or gani zat i ons  in  which  tne  network  Is 
centrally  funded  and  is  intended  as  a 
centralized  means  of  investigation  of 
particular  problems  (e.g.,  large-scale 
command  and  control  systems).  Existence 
of  NMIC  will  provide  a  means  for  semi - 
automating  conf i gur at i on  control  through 
establishment  of  data  bases  describing 
salient  properties  of  hosts,  files,  and 
program  resource  requ 1 rements. 

The  existence  of  these  data  bases 
will  also  be  of  interest  in  resolving  two 
other  problems  cf  concern  In  command  ant 
control  systems:  (I)  workload  reallocation 
to  provide  for  continuing  effective  pro¬ 
cessing  in  the  presence  of  outages 
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originating  during  a  stress  situation,  and 
(2)  reallocation  of  required,  but  not 
essentia),  workload  from  sites  suffering  a 
processing  overload  to  less  heavily  loaded 
sites  during  periods  of  peak  processing. 
Thus,  the  first  problem  effectively 
requires  a  fail-soft  capaoility  in  the 
face  of  equipment  malfunction  or  destruc¬ 
tion,  while  the  second  reflects  the  fact 
that  proper  functioning  of  an  installation 
requires  processing  of  both  the  stress- 
induced  workload  and  other  workload  com¬ 
ponents  during  lengthy  stress  situations. 

Network  reliability  Is  a  major  topic 
of  concern  to  users  faced  with  deadlines 
and  increased  manpower  costs  occurring 
because  of  an  inability  to  access  network 
resources.  The  number  of  distinct 
resources  in  a  computer  network  both  make 
it  highly  probable  that  cne  or  more 
resources  will  be  unavailable  during  a 
given  time  interval  and  simultaneously 
preclude  a  st r ai ght forward  redundancy 
approach  to  reliabilltv  (because  of  bud¬ 
getary  limitations).  However,  the  network 
and  the  global  sharing  of  resources  which 
it  affords  provide  an  opportunity  to 
achieve  reliability  through  dynamic 
migration  of  jobs  and  files.  The 
requirements  and  costs  for  such  a  software 
approach  to  reliability  constitute  an 
Interesting  subject  for  future  study. 


Sizing  individual  hosts  to  handle 
peak  loads  is  a  problem  of  continuing 
concern.  If  sufficient  resources  are 
required  to  handle  peak  loads  while  pro¬ 
viding  satisfactory  resources,  slonlf- 
icant  average  excess  capacity  may  result; 
conversely,  if  sizing  Is  performed  to 
permit  good  service  for  the  average 
workload,  peak  load  processing  may  suffer. 

Workload  migration  to  permit  effec¬ 
tive  peak  lead  processing  could  be  a 
viable  and  cost-effective  solution  within 
homogeneous  ( subnetworks.  In  a  crude 
sense,  remote  job  entry  capabilities  pro¬ 
vide  one  form  of  such  mlgrational  capa¬ 
bilities.  The  extent  to  which  these 
capabilities  can  be  realized  dynamically 
is  a  significant  research  topic  whose 
resolution  requires  information  concerning 
network  capabi 1 1 1 i es ,  user  loads,  and 
resource  requirements.  Much  of  this 
information  is  potentially  available  in 
the  data  base  maintained  by  NMlC. 

The  diversity  of  funding  sources  and 
or gani zat ions  represented  on  the  ARPANET 
limit  widespread  application  of  a  central¬ 
ized  approach  to  sizing  and  selecting 
network  resources.  However,  organ! zatl ons 
possessing  large  collections  of  computer 
systems,  e.g.,  command  and  control  systems 
or  logistics  systems,  are  often  con- 
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strained  by  a  fixed  allocation  of  funds 
for  procurement  of  the  entire  system. 
Thus,  dynamic  vorxload  migration  promises 
significantly  increased  system  capabl I  - 
I  ties  within  fixed  budgetary  constraints. 

SUMMARY 

A  tr I  a  1 -and-error  approach  to  network 
performance  promises  to  be  disastrous. 
Network  management  requires  cons  1 der at  1  on 
of  both  tecnnologl cal  and  organizational 
Issues,  and  the  dimensions  of  a  network 
demand  the  development  of  tools  to  facil¬ 


itate  management  assessment  of  these 
issues.  Such  tools  can  be  achieved 
through  a  coordinated  approach  Involving 
data  gathering,  trans format  1  on  of  data 
Into  Information,  information  display,  and 
alternatives  assessment.  Subsaturation  be¬ 
havior  of  a  network  permits  a  hierarchical 
approach  to  performance  projection  which. 
In  turn,  permits  development  of  appropri¬ 
ate  managerial  tools.  In  addition  to  as¬ 
sisting  in  network  management,  these  tools 
will  also  beofsignifi cant  use  to  other 
projects  requiring  networking  capabi  1 1 1 i es. 


REFERENCES 

1  Kleinrock,  L.,  “On  Measured  Behavior  of  the  ARPA  Network,-  Proceedl ngs  of  the  1 974 

Nat  I onal  Computer  Conference,  pp.  767-780. 

2  Balzer,  R.  M. ,  T,  E.  Cheatham,  and  S.  Crocker,  Nat  Iona  1  Sof tware  Works  Desl gn, 

USC  / 1  nf  or  mat  l  on  Sciences  Institute,  JSI/RR-73-16  On  progress) . 

3  - ,  The  Nat lonal  Sof tware  Works,  USC/ Informat  Ion  Sciences  Institute,  ISI/RR-73-18 

(In  progress ). 

i*  Kimbleton,  S.  R.,  "An  Analytic  Framework  for  Computer  System  Sizing  and  Tuning," 

P/oceedi ngs  of  tne  NBS/ACM  Computer  Per  formance  Eva luat ion  Workshop,  San  Diego, 
Cal  1 fornl a,  March  1^73.  Ofso  appeared  as  P-51 627  The  Rand  Corporation,  Santa 
Monica,  California,  January  1974. 

5  Ellis,  T.  0.,  L.  Gallenson,  J.  F.  Heafner,  and  J.  T.  Melvin,  A  P Ian  for 

Conso I I  dat i on  and  Automat  1  on  of  Ml  1 1  tar  y  Tel ecomrouni cat  i  ons  on  Oahu, 
USC/Informatlon  Sciences  InstI  tute,~"TS  I/RR-73-1  2,  May  T97X 

6  Boehm,  8.  W. ,  T.  E.  Bell,  and  3.  Jeffery,  eds.,  "Introductory  Comments"  In 

Proceedings  of  the  NBS/ACM  Computer  Performance  Evaluation  Workshop,  San  DIeqo, 
TT^TornTaT  M«rch“T97i: - - 

7  Kleinrock,  L.,  "Analytic  and  Simulation  Methods  In  Computer  Network  Design."  AT  IPS 

Conference  Proceedl ngs,  1970  Spring  Joint  Computer  Conference,  pp.  569-579. 

8  Frank,  H,  ,  I.  T.  Fr J sch,  and  W.  Chou,  "Topological  Cons Iderations  In  the  Design  of 

the  ARPA  Computer  Network,"  AF  PS  Conference  Proceedl ngs ,  1970  Spring  Joint 
Computer  Conference,  pp.  581-587. 

9  Frank,  H.,  R.  £.  Kahn,  and  L.  Kleinrock,  "Computer  Communication  Network 

Design — Experience  with  Theory  and  Practice,"  AFIPS  Conference  Proceedings.  1972 
Spring  Joint  Computer  Conference,  pp.  255-270. 

10  Kimbleton,  S.  R. ,  A  Fast  Approach  to  Computer  System  Per formance  Prediction, 

USC/ Inf  ormat  I  on  Sciences  InstI  tute,  IS  J/RR-74-20  (In  progresj.T! 


106 


RESEARCH  RESOURCES 


PROvlECT  LEADER*  Thomas  L.  Boynton 

RESEARCH  STAFF:  Robert  E.  Hoffman 

Jeff  Jacobs 
John  J.  Vi t r a  1 

CONTRIBUTING  STAFF  :  Louis  Ga  Henson 

Robert  H.  Parker 
Leroy  C.  Richards. n 

RESEARCH  STAFF  SUPPORT:  Jerry  Pipes 

Deborah  E.  Williams 

STUDENT  AIDES:  Danny  L.  Charlesvorth 

Dale  Chase 
Ronald  L.  Currier 
Nark  Ho 'ton 
Jimmy  T-  Koda 
Kyle  Lemmons 
Hargaret  Nathers 


INTRODUCTION 

The  I  SI  tine-sharing  facility  is 
operated  as  a  research  and  service  center 
in  support  of  a  broad  set  of  AdPA 
projects-  It  currently  services  Eou 
users,  8$  percent  of  vnom  access  the 
facilities  v;a  the  ARPANET  from  locations 
extending  from  London,  Englanu  *o  Havai i • 
All  facilities  of  the  operating  system  are 
available  to  all  users,  whether  they  are 
connected  through  the  ARPANE1  locally  or 
rer  ate  I  y. 

1  he  system  consists  of  two  Digital 
Lguipment  Corporation  PDP-lu  CPUs,  Bolt 
Beranek  and  Newman  paui ng  box, 
large-capacity  memory,  hi  gh-per  f  orrrance 


pacing  drum,  on-line  file  storage,  and 
associated  peripherals  (see  Figure  1 0.1). 
In  conjunction  with  the  large  core  and 
di  uni  memory,  the  BIN  TEN  EX  operating 
system  provides  considerable  computing 
capacity  ind  is  capable  of  supporting  a 
wine  variety  of  simultaneous  u:ers. 

GENEkAL  BYS1EM  UPGRADING 

In  a  continuing  effort  to  improve 
system  avai labi I i ty,  capacity,  and 
efficiency,  add t ions  have  been  made  in 
hardware  and  software  and  in  support 
per sonne 1 . 

Hardware 

The  hardware  acquired  in  the  past 
year  as  part  of  ».  .  general  upgrading 
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effort  includes  a  second  POP- 10  CPU,  an 
additional  128K  of  high-speed  (850-nsec) 
memory,  six  CALCOMP  230  disk  drives  that 
will  approximately  double  the  rresent 
on-line  file  storage,  and  several 
interfaces  and  switches  designed  and  built 
at  ISI.  Figure  10. 1  shows  the  current  ISI 
POP- 10  configuration.  Note  that  the  two 
CPU's,  the  KA-10  and  the  new  KI-10f  do  not 
operate  in  a  dual  CPU  mode.  Instead,  the 
main  goal  of  having  the  two  CPU's  and  the 
switches  is  to  provide  a  significant 
increase  in  the  availability  of  the  ISI 
■primary11  machine.  Thus  if  the  CPU  acting 
as  the  primary  machine  breaks  down  or 
is  needed  for  preventive  Hardware 
maintenance,  system  software  maintenance, 
or  development,  then  the  other  CPU  may  be 
started  as  the  primary  machine  and  service 
continued  after  a  brief  (15-30  minutes) 
interruption  to  switch  machines.  This 
ability  to  switch  machines  is  made 
possible  by  the  several  components 
described  below. 

A  second  copy  of  the  ISI  ARPANET-10 
interface  produced  for  the  KI-10  is  now 
operational.  This  interface,  together 
with  the  first  ISI  ARPANET- 10  interface 
running  on  the  KA-10f  Is  attached  to  an 
I SI-_esi gned  electronic  IMP  switch  that 
allows  the  interfaces  to  be  easily 


switched  from  one  distant  IMP  port  to  the 
other.  The  purpose  of  this  switch  is  to 
allow  either  of  the  two  PDP-10's  to  assume 
the  identity  of  the  primary  outside  user 
machine  on  the  ARPANET  and  to  allow  rapid, 
error- free  changeover  from  one  primary 
machine  to  the  other. 

Electronic  PUP-10  1/0  bus  switches 
have  also  been  designed  and  developed  to 
allow  the  two  PDP-10  ^  to  share  peripheral 
equipment  (see  Figure  10.2).  The  two 
PDP-10  buses  can  be  looped  through  each 
switch.  A  single  stub  slot  is  provided  to 


unswitched  .  unswitched 

devices  i  devices 


Figure  10.2  I/O  bvs  switch 
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allow  *dalsy-chal nlng"  of  peripheral 
devices.  The  switch  accommodates  either 
KA  or  KI  I/O  buses,  but  the  stub  slot 
accommodates  a  KA  bus  only.  The  switch 
also  has  a  center  off  position  to  detach 
the  switched  peripheral  equ! pme-t  from 
both  machines  for  preventive  maintenance 
or  service.  When  the  switch  Is  thrown,  a 
half-second  timer  resets  the  peripheral 
device  and  then  engages  the  device  onto 
the  main  computer  bus  to  provide 
trouble-free  switch* no.  Two  complete 
switches  are  now  operational,  one 
switching  the  DECtapes  and  the  other  the 
magnetic  tapes  between  the  KA-10  and 
KI-10. 

In  order  to  alert  operators  to  system 
malfunctions  more  quickly,  one  Interface 
not  previously  reported  has  been 
Implemented  for  the  primary  machine.  A 
"watchdog"  or  "deadman"  timer  monitors  the 
CPU,  tripping  both  a  visual  alarm  at  every 
terminal  and  an  audible  alarm  on  each 
floor  of  I  SI  If  the  CPU  goes  down.  The 
alarm  has  an  override  feature  and  a 
silence  feature  that  overrides  either  the 
two  types  of  alarms  or  only  the  audible 
alarm,  respectively. 

The  new  CALCOMP  disk  system  also  wl 11 
contribute  to  the  ability  to  switch 


primary  machines  quickly  by  making  It 
possible  to  switch  the  disk  controller 
from  one  machine  to  the  other  using  Its 
two-channel  sw! tch  feature. 

Software 

The  d^na^d  for  I  Si's  computing 
capacity  far  exceeded  supply  for  most  of 
the  year,  and  a  way  was  needed  to  reduce 
the  load  on  the  system  and  to  restrict 
access  to  designated  users  at  scheduled 
times,  as  specified  by  ARPA  and  ISI 
managements.  In  March,  ISI  Installed  a 
modified  version  of  the  group  allocation 
scheme  developed  at  Stanford  Research 
Institute  for  controlling  user  access  to 
the  POP- 10.  Tl  e  group  allocation  scheme, 
as  modified  by  ISI,  divides  the  total 
number  of  Job  slots  available  on  the 
system  Into  two  categories:  general -access 
slots  permitting  full  use  of  the  system 
and  limited-access  slots  restricting  the 
user  to  certain  facilities,  principally 
message  and  text  editing  activities. 
These  access  slots  are  further  subdivided 
Into  groups,  with  each  group  defined  by 
the  names  of  group  members  and  by  a  quota 
(which  may  vary  In  size  throughout  the 
day)  that  specifies  the  number  In  that 
group  guaranteed  access  to  the  system  for 
general  use.  For  most  groups,  the  number 
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of  group  members  Is  much  greater  than  the 
quota,  and  a  user  may  therefore  not  be 
able  to  log  In  on-quota.  If  the  system  as 
a  whole  Is  still  under  quota  (because  some 
other  group  Is  not  at  quota),  then 
the  user  will  be  permitted  to  log  In 
off-guota.  If  the  slot  taken  up  by  an 
off-quota  user  Is  later  needed  to  serve  a 
new  nn-quota  user,  tnen  the  off-quota  user 
Is  given  a  flve-ml r.ute  warning  and  logged 
off. 

Management  designates  the  group 
members  and  the  quotas  tor  each  group 
throughout  the  da  '.  By  setting  the 
system's  totjl  available  quota  to  a 
sufficiently  low  level,  management  can 
reduce  the  load  on  the  system  so  that 
those  who  can  log  on  will  f l nd  the  system 
responsive  and  effective.  Although  the 
qroup  allocation  system  does  not  directly 
allocate  the  scarce  central  processing 
capacity,  the  ISI  systei.,  supports  enough 
users  that  the' r  requests  usually  make  an 
acceptable  average  central  processor 
oemand.  In  all,  the  Initial  experience 
with  group  allocation  has  been  good. 

Before  group  allocation  was  In¬ 
stalled,  a  program  was  developed  to 
monitor  the  system  load  and 


operator  when  It  exceeded  a  tolerable 
level.  Selected  Individuals  were  then 
asked  to  temporarily  stop  their  computing. 
The  program  Is  now  being  useo  to  monitor 
the  working  of  group  allocation  and  to 
provide  statistics  on  system  usage.  In 
order  to  understand  load  problems,  s«veral 
analysis  programs  were  developed  that 
display  the  system  use  data  for 
manaoement. 

Support  Personnel 

ISI  has  hired  and  trained  stu¬ 
dent  operators  to  provide  twenty-four- 
hour  machine  service.  The  primary 
responsibility  of  the  operator  Is  to 
assist  the  system  staff  In  maintaining  the 
operating  system  and  assuring  the 
contl  ntjous  functioning  of  the  overall 
system.  The  on-duty  operator  Is 

principally  engaged  In  running  •■ystem 
maintenance  programs  and  monitoring 
^achl  >e-room  equipment.  The  latter 
function  Includes  detecting  failure*  on 
the  computer  or  Its  support  equipment, 
taking  corrective  action,  and  notifying 
appropriate  system  personnel  In  the  event 
of  a  nonrecoverable  failure. 
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LOCAL  PROJECT  SUPPORT 

The  TENEX  facility  has  been  utilized 
extensively  in  support  of  local  projects. 
The  staff  makes  use  of  all  of  the 
available  standard  subsystems  (e.  g., 
editors,  compilers,  assemblers,  and 
utilities).  Addi ti ona 1 1 y,  staff  members 
have  written  subsystems  and  utilities  In 
support  of  their  own  projects  (e.  g.,  a 
program  for  copying  POP- 1i  programs  to  the 
PDP-11 's  and  TENEX  accounting  package 
extensions).  The  facility  has  supported 
less  frequently  used  subsystems  at  the 
special  rf ^uest  of  users  (e.  g.,  PDP-11 
cross  assemblers  and  the  DECUS  Scientific 
Subroutin.  Package). 

ISI  has  also  taken  delivery  of  three 
DEC  PDP-ll's.  One  of  these,  an  11/45,  is 
described  in  Section  7.  The  other  two  are 
»1/40's  intended  to  support  the  XGP's  (see 
Section  6).  One  11 /AO  is  being  used  until 
new  IMP  ports- are  provided  in  two  modest 
during  the  day  the  PDP-11  serves  as  many 
as  16  local  terminal  users  as  a  local 
terminal  support  processor  to  the  ARPANET, 
and  at  night  it  supports  the  XGP. 

An  ISI-designed  interface,  the  ISI 
ARPAhET-ll  interface,  provides  a  local 
hot t  connection  to  an  ARPANET  IMP  for  any 
model  PDP-11  minicomputer.  The  interface 


operates  in  full-duplex  mode  to  the  IMP, 
employing  four-way  handshaking  of  serial 
data.  A  direct  memory  access  capability 
allows  the  Interface  to  operate  from 
PDP-11  memory  directly  for  data  transfers 
without  the  intervention  of  the  PDP-11 
CPU.  The  dialogue  with  PDP-11  memory  is 
handled  on  a  starting  address  and  byte 
count  basis,  where  each  half  of  the  duplex 
interface  operates  Into  or  out  of  a  unique 
buffer  area  in  core. 

Hardware  features  of  the  interface 
include  a  capability  for  byte  swapping  on 
a  per-word  basis,  four  diagnostic  inodes 
(LOCK,  LCOP ,  TEST  INC,  and  LOCAL), 
extended  memory  capability,  complete 
control  panel,  separate  power  supply,  odd 
output  starting  address  and  odd  byte  count 
capability,  output  buffer  chaining,  a 
factor-of- f our  size  reduction  over  other 
existing  designs,  modularity  (each  half  of 
the  interface  Is  one  unique  card),  low 
power  consumption  (27  watts),  and  a  total 
front  panel  space  (including  control 
panel)  of  only  1 U- 1/2  inches.  Two  ISI 
ARPANET-11  interfaces  are  now  operational, 
one  supported  by  the  POP- 11/4$  running  ELF 
(port  of  the  speech  processing  effort)  and 
the  other  support  :d  on  a  POP- 1 1/40  running 
ELF  with  up  to  sixteen  ARPANET  users.  ELF 
Is  a  multiuser  PDP-11  operating  system 
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developed  by  Speech  Communications 
Research  Laboratory,  Santa  Barbara,  spec¬ 
ifically  designed  to  a  I  lev  POP- II 's  to 
be  attached  to  the  ARPANET. 

MLP-900  PROCESSOR 

Monitor  nodi f Icatlons  to  support  the 
initial  Installation  and  checkout  of  the 


MLP-900  have  been  developed  and  verified. 
These  modifications  allow  basic  pro¬ 
cessor-  to-processor  communication  through 
both  the  I/O  bus  and  memory.  This  Is  the 
first  step  In  a  multlstep  plan  for  fully 
Integrating  the  MLP  Into  the  TENEX 
operating  system  (see  Section  3). 
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INTRODUCTION 

The  project  goals  from  July  1973  to 
December  1973  have  been  to  1}  evaluate  the 
technological  feasibility  of  signif¬ 
icant  advancements  In  computer-based 
manufacturing  systems  for  discrete  product 
manufacture?  2)  evaluate  the  economic 
Impact  on  the  OoO  and  the  U.  S.  economy 
resulting  from  the  Implementation  of  those 
advancements;  and  3)  define  the  specific 
development  program  and  resources  requl red 
to  achieve  those  advancements.  The 
evaluations  and  recommendations  of  the 
project's  staff  were  provided  to  ARPA  In  a 
final  report  on  the  study  phase  of 
the  project  [l]#  consisting  of  a  major 
economic  analysis  of  the  costs*  labor*  and 
Industry-structure  factors  character  I zl ng 
DoO  procurement.  In  addition*  the  report 
presented  several  detailed  case  analyses 
of  particular  OoO-related  manufacturing 
operations  In  order  to  facilitate 


the  understanding  of  the  manufacturing 
enterprise  as  a  system. 

The  following  selection  describing 
the  project's  achievements  and  expected 
impact  Is  taken  from  the  Preface  to  that 
report. 

In  October  1971,  a  research  effort  was 
begun  at  the  request  of  the  Advanced  Re¬ 
search  Projects  Agency  of  the  Department  of 
Defense  to  investigate  the  feasibility  of  sig¬ 
nificant  production  advancements  using 
computer-based  manufacturing  technology 
and  to  evaluate  the  impact  such  advance¬ 
ments  might  have  on  DOD  procurement  of 
manufactured  goods 

This  report  presents  specific  recommen¬ 
dations  for  a  major  high-impact  ARPA- 
spon sored  research  and  development  pro¬ 
gram  in  advanced  computer-based  manu¬ 
facturing  technology,  including  the  objec¬ 
tives,  required  level  of  effort,  milestones, 
and  duration  of  such  a  program.  The  eco¬ 
nomic  analysis  in  this  report  also  provides  a 
major  source  of  information  on  many  key 
characteristics  of  DOD-related  manufactur¬ 
ing  industries.  The  data  obtained  in  the 
course  of  our  study  will  be  of  great  impor¬ 
tance  to  other  governmental  agencies  and  to 
research  contractors  in  formulating  and 
evaluating  complementary  research  and  de¬ 
velopment  programs  in  computer-based 
manufacturing. 
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PROJECT  STATUS 

The  Project  vas  terminated  at  the 
close  of  the  study  phase  by  mutual 
agreement  of  ARPA-IPTO  and  ISi.  At  the 


time  It  vas  concluded  that  It  vould  not  be 
possible  to  adequately  staff  a  combined 
research  and  development  effort  to  explore 
fully  the  conclusions  of  the  final  report. 
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